Integration von Suchmaschinen in die Corporate Knowledge

Transcription

Universität-Gesamthochschule Paderborn
Diplomarbeit
Integration von Suchmaschinen in die Corporate
Knowledge Management Plattform einer internationalen
Großbank
Problemanalyse und Konzeption eines Lösungsansatzes anhand
einer prototypischen Implementation
Prof. Dr. Ludwig Nastansky
Wintersemester 1999/2000
Betreuer:
Dipl.-Inform. Stefan Smolnik
vorgelegt von:
Guido Koert
Wirtschaftsinformatik
Matr.-Nr.: 3059310
Am Roden 36
59846 Sundern
Eidesstattliche Erklärung
Ich erkläre hiermit an Eides Statt, daß ich die vorliegende Arbeit selbständig und nur
unter Verwendung der angegebenen Hilfsmittel angefertigt habe; die aus fremden
Quellen direkt oder indirekt übernommenen Gedanken sind als solche kenntlich gemacht.
Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch noch nicht
veröffentlicht.
Paderborn, den
..........
.................
(Datum)
(Unterschrift)
Verzeichnisse
Inhaltsverzeichnis
1
Einleitung ............................................................................................................ 1
1.1 Szenario ............................................................................................................ 1
1.2 Zielsetzung........................................................................................................ 2
1.3 Vorgehensweise ................................................................................................ 3
2
Technologische Grundlagen und Thematikabgrenzung.................................... 5
2.1 Die Entwicklung des World Wide Webs ........................................................... 5
2.2 Suchmaschinen als ordnende Instanzen im WWW .......................................... 10
2.2.1 Historische Betrachtung von Suchmaschinen........................................... 10
2.2.2 Abgrenzung des Begriffs Suchmaschine .................................................. 14
2.2.3 Architektur und Vorgehensweise von Suchmaschinen ............................. 16
2.2.4 Spezielle Suchmechanismen für Lotus Notes/Domino ............................. 18
2.3 Lotus Notes/Domino R5.................................................................................. 19
2.4 NetFicient Release 2 ....................................................................................... 21
2.5 Technologische und konzeptionelle Rahmenbedingungen ............................... 23
3
Problemanalyse ................................................................................................. 25
3.1 Webtechnologien ............................................................................................ 25
3.1.1 Das Hypertext Transport Protocol............................................................ 25
3.1.2 Hypertext Markup Language ................................................................... 27
3.1.3 Java ......................................................................................................... 32
3.2 Lotus Notes/Domino Release 5 ....................................................................... 32
3.2.1 Lotus Domino als Webserver................................................................... 33
3.2.2 Design Elemente von Lotus Notes ........................................................... 36
3.2.3 Konfiguration des Domino-Servers.......................................................... 40
3.3 Suchmaschinensoftware .................................................................................. 42
3.4 Kernanforderungen an NetFicient R2 .............................................................. 43
i
Verzeichnisse
4
Evaluierung von Lösungsansätzen ................................................................... 45
4.1 Korrekte Erfassung der Webseiten durch Spider und Indexer .......................... 45
4.1.1 Manipulation der HTTP-Header unter Lotus Domino .............................. 46
4.1.2 Lösungsansätze für nicht unterstützte HTML-Funktionen........................ 48
4.1.3 Unterstützung von JavaScript und Java-Applets....................................... 50
4.1.4 Suchmaschinengerechte Webdarstellung der Notes-Elemente.................. 51
4.1.5 Implementation einer speziellen Suchseite............................................... 53
4.2 Unterstützung der Suchmaschinensoftware ..................................................... 54
4.2.1 Korrekte Einordnung der Seiten in den Trefferlisten ................................ 55
4.2.2 Konzeption eines leistungsfähigen Suchinterfaces ................................... 58
4.2.2.1 Obligatorisch zu unterstützende Funktionalitäten................................. 59
4.2.2.2 Benutzerfreundliche Umsetzung der benötigten Funktionen................. 61
4.3 Sicherheitsaspekte........................................................................................... 63
5
Lösungskonzept zur Integration von Suchmaschinen in NetFicient............... 65
5.1 Lösungsansatz und Vorgehensweise................................................................ 65
5.2 Programmierung der Meta-Informationen im HTTP-Header und HTML-Head 66
5.3 Generierung eines Suchbaumes zur Unterstützung der Spider.......................... 68
5.4 Trennung von Seiteninhalt und Meta-Informationen........................................ 71
5.5 Verifikation des entwickelten Konzeptes......................................................... 72
5.5.1 Testumgebung und Vorgehensweise........................................................ 72
5.5.2 Analyse der Testergebnisse...................................................................... 74
6
Ausblick............................................................................................................. 78
7
Zusammenfassung............................................................................................. 80
8
Literaturverzeichnis.......................................................................................... 82
ii
Verzeichnisse
9
Anhang .............................................................................................................. 86
9.1 Zusätzliche Informationen zum Thema Suchmaschinen................................... 86
9.1.1 Liste der Suchmaschinen im WWW ........................................................ 86
9.1.2 Spider Spotting Chart .............................................................................. 95
9.2 HTTP-Header Informationen des Domino-Servers .......................................... 97
9.3 Dokumentation des entwickelten Prototyps ..................................................... 99
9.4 Protokollierung des Proof of Concepts .......................................................... 101
9.4.1 Protokoll vom 30.09.1999 ..................................................................... 101
9.4.2 Protokoll vom 24.11.1999 ..................................................................... 105
9.4.3 Logdatei des Verity-Spiders .................................................................. 108
iii
Verzeichnisse
iv
Abkürzungsverzeichnis
Abb.
Abbildung
ACL
Access Control List
ARPA
Advanced Research Projects Agency
ASCII
American Standard Code for Information Interchange
ASP
Active Server Pages
CERN
Centre Européen pour la Recherche Nucléaire
CGI
Common Gateway Interface
CORBA
Common Object Request Broker Architecture
FAQ
Frequently Asked Questions
FTP
File Transfer Protocol
HTML
Hypertext Markup Language
HTTP
Hypertext Transport Protocol
IRC
Internet Relay Chat
ISO
International Standard Organsiation
ITSO
International Technical Support Organisation
KM
Knowledge Management
MIME
Multipurpose Internet Mail Extension
NNTP
Network News Transfer Protocol
PDF
Portable Document Format
RFC
Request for Comments
SMTP
Simple Mail Transfer Protocol
TCP/IP
Transmission Control Protocol/Internet Protocol
URL
Uniform Resource Locator
Veronika
Very Easy Rodent-Orientated Netwide Index to Computerized Archives
WAIS
Wide Area Information System
WWW
World Wide Web
Verzeichnisse
Verzeichnis der Abbildungen
Abb. 1:
Aufbau und Struktur von HTML-Dokumenten ........................................... 9
Abb. 2:
Suchmaschinen-Abdeckung des WWW (Quelle: Lawrence/Giles 1998) .. 12
Abb. 3:
Aufbau von mehrfach verteilten Systemen................................................ 13
Abb. 4:
Vorgehensweise von Suchmaschinen........................................................ 16
Abb. 5:
Architektur des Domino-Servers............................................................... 20
Abb. 6:
Knowledge Management mit NetFicient................................................... 22
Abb. 7:
Aufbau der untersuchten Framesets .......................................................... 29
Abb. 8:
HTML-Quelltext zur Generierung eines einfachen Framesets ................... 29
Abb. 9:
Hauptnavigation in NetFicient als Image Map .......................................... 30
Abb. 10:
HTML-Quelltext für eine Image Map ....................................................... 31
Abb. 11:
HTTP-Header für eine Page mit Pass Thru HTML ................................... 35
Abb. 12:
JavaScript und Pass Thru HTML .............................................................. 37
Abb. 13:
Verwenung von Domino-Applets zur Darstellung beim Webzugriff ......... 38
Abb. 14:
Domino-Ansicht als HTML-Tabelle mit Navigation ................................. 39
Abb. 15:
Serverkonfiguration für die Domino Web Engine ..................................... 42
Abb. 16:
Suchergebnis für Bonitätsprüfung bei Altavista ........................................ 43
Abb. 17:
Räumliche Abgrenzung des Suchfokus ..................................................... 60
Abb. 18:
Andvanced Search von Infoseek ............................................................... 62
Abb. 19:
Maske zur Eingabe der Informationen für die Suchmaschine .................... 67
Abb. 20:
Programmierung des HTML-Head in Notes.............................................. 67
Abb. 21:
Lenkung des Spiders durch den Suchbaum ............................................... 68
Abb. 22:
Berechneter Link für die Suchansicht ....................................................... 69
Abb. 23:
Quelltext für den Next-Link der Suchansicht ............................................ 70
Abb. 24:
Auszug aus der Logdatei des Verity-Spiders............................................. 75
Abb. 25:
Auszug aus der Trefferliste von Verity ..................................................... 76
v
Verzeichnisse
Abb. 26:
Konfiguration der Verity-Suchmaschine ................................................. 101
Abb. 27:
Proof of Concept – Trefferliste vom 30.09.1999, Teil 1/2 ....................... 103
Abb. 28:
Abb. 29:
Abb. 30:
vi
Verzeichnisse
Verzeichnis der Tabellen
Tabelle 1:
Die größten und populärsten Suchmaschinen (Quelle: Sullivan 1999).... 15
Tabelle 2:
Von Suchmaschinen nicht unterstützte HTML-Funktionen .................... 28
Tabelle 3:
Zusammenhänge zwischen Notes-Elementen und HTTP-Header ........... 35
Tabelle 4:
Probleme in Abhängigkeit von der Webdarstellung der Notes-Elemente 40
Tabelle 5:
Faktoren, die das Ranking der Suchmaschinen beeinflussen................... 55
Tabelle 6:
Faktoren zur Beeinflussung der Trefferliste ........................................... 57
Tabelle 7:
Logische Operatoren für Suchanfragen (vgl. Altavista 1999) ................. 59
Tabelle 8:
Ausdrücke zur Abgrenzung des Suchfokus (vgl. Altavista 1999) ........... 60
Tabelle 9:
Unterstützte Sicherheitsstandards........................................................... 63
Tabelle 10: Spider Spotting Chart ............................................................................ 96
Tabelle 11: Liste der HTTP-Header in Abhängigkeit der Notes-Elemente ................ 98
vii
Einleitung
1
1 Einleitung
1.1 Szenario
Das Internet hat in den letzten Jahren zunehmend an Bedeutung gewonnen. Gerade mit
der Einführung des World Wide Web (WWW oder das Web) ist eine eigene Präsenz im
Internet für viele Unternehmen zu einem wettbewerbsfördernden Faktor geworden.
Doch neben Marketing und geschäftlichen Anwendungen wie Ecommerce ist der ursprüngliche und primäre Nutzen des Internets nach wie vor die schnelle, globale Informationsbeschaffung und –verbreitung (vgl. Casselberry 1997, S. 174).
Seit seinem Ursprung Ende der sechziger Jahre ist das Internet sprunghaft gewachsen.
Allein das WWW umfaßte Anfang 1998 nach einer Schätzung des NEC Research Institute über 320 Millionen Seiten (vgl. Lawrence/Giles 1998, S. 198). Diese „...größte
Infothek der Welt“ (Luckhardt 1998, S. 88) enthält wertvolle Informationen zu fast allen
Themenbereichen, deren effektive Nutzung einen entscheidenden Wettbewerbsvorteil
darstellen kann. Um in diesen riesigen Datenmengen die Informationen zu finden, die
man benötigt, sind effiziente Suchmöglichkeiten erforderlich. Sogenannte Suchmaschinen und –dienste wie z. B. Altavista oder Yahoo gehören daher nicht umsonst zu den
meist genutzten Diensten im WWW (vgl. Knut/Bager 1997, S. 170).
Wichtig für die eigene Webpräsenz ist daher nicht nur die funktionelle Gestaltung der
eigenen Seiten, sondern auch die leichte Auffindbarkeit. Dafür ist es nötig, daß die eigenen Seiten von Suchmaschinen erfaßt werden und bei relevanten Suchanfragen in der
Trefferliste der Suchmaschinen möglichst weit oben plaziert werden, da sie sonst im
riesigen Informationsangebot des WWW keine Beachtung finden.
Die Deutsche Bank AG hat zur eigenen Informationsverbreitung im Intranet und Internet mit NetFicient eine proprietäre Lösung auf Basis der Groupware-Plattform Lotus
Notes/Domino entwickelt. In der Konzeption der neuen Release soll diese ursprünglich
für das Web-Publishing entwickelte Anwendung zu einer Knowledge Mangement (KM)
Plattform ausgebaut werden. Ein wichtiger Bestandteil dieser Weiterentwicklung ist
aufgrund der oben beschriebenen Thematik die Integration von Suchmaschinen. Diese
beinhaltet zwei wesentliche Aspekte. Zum einen soll gewährleistet werden, daß die mit
NetFicient erstellten Seiten von internen und externen Suchmaschinen verarbeitet werden können, um somit zu gewährleisten, daß aus dem Intranet und Internet auf diese
Einleitung
2
Informationen effizient zugegriffen werden kann. Zum anderen soll zur Unterstützung
der
KM-Funktionalitäten ein leistungsfähiges Suchinterface in Netficient integriert
werden, um Informationen aus dem Intranet sowie dem Internet effizienter nutzen zu
können.
1.2 Zielsetzung
NetFicient wurde von der Deutschen Bank AG ursprünglich als Web-Publishing-Tool
konzipiert und eingesetzt, d. h. es sollte den Anwendern ermöglicht werden, auch ohne
spezifische Kenntnisse wie HTML (Hypertext Markup Language), Java etc. einfach und
schnell ansprechende und funktionelle Inhalte im Intranet und Internet zu veröffentlichen. Bedingt durch die Größe des firmeneigenen Netzes wurden neue Technologien
wie Knowledge Management erforderlich, um die vorhandenen Informationen effizient
zu nutzen und in einen Geschäftsvorteil umzusetzen. Die Unterstützung und Integration
von Suchmaschinen in NetFicient Release 21 ist daher von den planenden Entwicklern
als eine wichtige Anforderung für die Weiterentwicklung zu einer KM-Plattform formuliert worden (vgl. Deutsche Bank AG 1999a).
Ziel dieser Arbeit ist es, ein Konzept zu dieser Integration von Suchmaschinen in die
Publishing-Komponente von NetFicient zu entwickeln, wobei die korrekte Verarbeitung
der mit NetFicient publizierten Seiten durch interne und externe Suchmaschinen im
Vordergrund steht. Zudem wird in einer eingehenden Analyse die zugrundeliegende
Problematik bewußt gemacht, die durch die auftretenden Schwierigkeiten im Zusammenhang von Suchmaschinen mit Lotus Domino entsteht. Vor dem Hintergrund der
durch NetFicient gegebenen Anforderungen werden mehrere verschiedene Lösungsansätze evaluiert und gegebene Zielkonflikte aufgeführt. Zusätzlich wird, basierend auf
den Ergebnissen, ein Prototyp entwickelt, der zusammen mit dem Lösungskonzept den
Entwicklern in der anschließenden Implementationsphase der neuen Release von NetFicient als Grundlage dienen soll.
Ein weiterer betrachteter Aspekt dieser Arbeit ist die Unterstützung der Benutzer durch
ein leistungsfähiges Suchinterface. Ziel ist es, ein Konzept zu entwickeln, das sowohl
die Anforderungen an die Bedienbarkeit (engl. Usability) erfüllt als auch leistungsfähige
1
Im Verlaufe dieser Arbeit ist, wenn nicht anders angegeben, immer Release 2 gemeint.
Einleitung
3
Funktionen integriert, um den Anwendern eine effiziente Suche mit qualitativ zu bewertenden Ergebnissen zur Verfügung zu stellen.
1.3 Vorgehensweise
Um die im vorangegangen Abschnitt formulierte Zielsetzung zu erreichen, müssen zunächst die grundlegenden Technologien beschrieben und die verwendete Terminologie
definiert werden. Daher befaßt sich das anschließende 2. Kapitel mit den InternetStandards und –Technologien und grenzt die Themenbereiche dabei auf einen für diese
Arbeit relevanten Fokus ab. Vor allem die in den anschließenden Kapiteln wesentlichen
Grundlagen von Suchmaschinen und von der verwendeten Plattform Lotus
Notes/Domino in der aktuellen Release 5.0 stehen dabei im Vordergrund. Zudem werden die Knowledge Management Plattform NetFicient und die zu beachtenden Anforderungen vorgestellt. Schließlich werden die gegebenen technologischen und konzeptionellen Rahmenbedingungen abgesteckt.
In Kapitel 3 wird eine umfassende Analyse der zugrundeliegenden Problematik durchgeführt. Diese beinhaltet zunächst die Identifikation und Abgrenzung der wesentlichen
Problembereiche, wobei sowohl generell mit Suchmaschinen verbundene Schwierigkeiten als auch im Zusammenhang mit Lotus Domino im allgemeinen und NetFicient
im speziellen auftretende Probleme betrachtet werden. Danach werden die Problembereiche eingehend auf ihre Ursachen und Auswirkungen hin untersucht sowie deren Bedeutung für diese Arbeit beschrieben.
Darauf aufbauend werden in Kapitel 4 Lösungsansätze für die entsprechenden Teilprobleme entwickelt und evaluiert. Dabei werden existierende Standardlösungen vorgestellt, an die Problematik angepaßt und zusätzlich auch neue Konzepte und Lösungswege entwickelt. Zur Bewertung der einzelnen Ansätze werden deren Vor- und Nachteile
diskutiert und ihre jeweilige Eignung für NetFicient untersucht. Auch wird auf vorhandene Zielkonflikte von einzelnen Lösungen hingewiesen.
Basierend auf diesen Ergebnissen, wird dann ein umfassendes Lösungskonzept für die
Integration von Suchmaschinen in NetFicient entwickelt. Begleitend dazu wird ein
Prototyp entwickelt, der die praktische Umsetzung des Konzeptes in Lotus
Notes/Domino demonstrieren soll. Zudem findet der Prototyp Verwendung zur Verifikation der Ergebnisse in einem abschließenden Proof of Concept.
Einleitung
4
Der anschließende Ausblick befaßt sich mit zukünftigen Entwicklungen und Technologien, die im Zusammenhang mit der diskutierten Thematik relevant sind. Zudem wird
ein Vorschlag für eine Erweiterung der Suchmaschinenstandards vorgestellt, der die in
dieser Arbeit nicht zu lösenden Probleme adressiert.
Den Abschluß bildet eine Zusammenfassung, die noch einmal die wesentlichen Erkenntnisse und Ergebnisse dieser Arbeit in prägnanter Form präsentiert.
Darüber hinaus umfaßt der Anhang weitergehende Informationen zu dem Thema Suchmaschinen. Dies sind insbesondere Listen und Tabellen, die den Lesefluß im Hauptteil
der Arbeit gestört hätten. Zudem werden Protokolle der durchgeführten Tests sowie die
Dokumentation des entwickelten Prototyps aufgeführt. Der Prototyp selbst sowie die
benutzten Literaturquellen aus dem World Wide Web sind auf der beiliegenden CDROM zu finden.
Technologische Grundlagen und Abgrenzung der Thematik
5
2 Technologische Grundlagen und Thematikabgrenzung
Dieses Kapitel gibt eine Einführung in die grundlegenden Technologien, die in dieser
Arbeit diskutiert werden. Zudem wird eine Abgrenzung der Themengebiete auf einen
für die anschließenden Kapitel sinnvollen Fokus vorgenommen.
Zunächst wird die Entwicklung des Internets, besonders die des World Wide Webs und
die für diese Arbeit relevanten Standards und Konzepte beschrieben. Darauf aufbauend,
wird detailliert auf die Vorgehensweise und Architektur von Suchmaschinen eingegangen. Danach wird die Knowledge Management Plattform NetFicient des untersuchten
Unternehmens und die zugrundeliegende Groupware und Intranet Plattform Lotus
Notes/Domino Release 5 vorgestellt und dabei vor allem der Webserver und die neuen
Designelemente näher beschrieben. Abschließend werden die für diese Arbeit geltenden
technischen und konzeptionellen Rahmenbedingungen aufgeführt, die durch die eingesetzte Hard- und Software sowie die definierten Kernanforderungen der neuen Release
von NetFicient gegeben sind.
2.1 Die Entwicklung des World Wide Webs
Entgegen eines weitläufigen Irrtums ist das World Wide Web (WWW) nicht dem Internet gleichzusetzen. Vielmehr ist das WWW nur einer, wenn auch der populärste, der
zahlreichen Dienste, die das Internet als Basis benutzen. Daher wird im folgenden zunächst kurz auf die Entstehung und Entwicklung des Internets und seiner Dienste und
Standards eingegangen, bevor, darauf aufbauend, das WWW detaillierter beschrieben
wird.
Wie viele Entwicklungen in der Informatik und Informationstechnologie entstand auch
das Internet aus einem militärischen Projekt (vgl. Keil-Slawik 1996, S. 23). Unter der
Prämisse, auch bei größter anzunehmender Zerstörung nach einem atomaren Angriff
noch zu funktionieren, wurde auf Basis des Konzeptes der Paketverteilung (engl. packet
switching) Ende der sechziger Jahre das ARPANET (ARPA= Advanced Research Projects Agency) entwickelt, an dem neben militärischen Institutionen alle relevanten Firmen und Universitäten angeschlossen waren, die sich maßgeblich mit der militärischen
Forschung beschäftigten. Mit der Öffnung des ARPANET für die Wissenschaft und
dem damit verbundenen starken Anstieg der Anzahl vernetzter Rechner wurde ein einheitliches Protokoll zur Datenübertragung notwendig, wodurch das TCP/IP-Protokoll
6
(Transmission Control Protocol/Internet Protocol) entstand. In anderen Staaten, besonders in Europa, fanden ähnliche Entwicklungen statt, und mit der Kopplung der vielen
Einzelnetze entstand ein weltweites Netz, für das im Laufe der achtziger Jahre die Bezeichnung Internet eingeführt wurde (vgl. Münz/Nefzger 1998).
Das TCP/IP-Protokoll stellt die Basis für alle Datenübertragungen im Internet dar. Wie
der Name schon vermuten läßt, handelt es sich dabei eigentlich um zwei differenziert zu
betrachtende Protokolle. Das Transmission Control Protocol ist für die fehlerfreie
Übermittlung der Daten zuständig. Gemäß dem oben bereits erwähnten packet switching werden die Daten zur Übertragung in mehrere kleine Pakete aufgeteilt, die jeweils
einzeln an die Zieladresse geschickt werden, wo sie dann wieder zu der ursprünglichen
Nachricht zusammengesetzt werden. Dabei baut das TCP-Protokoll auf dem Internet
Protocol auf, welches für die Adressierung der Pakete verantwortlich ist. Dazu wird
jedem an das Internet angeschlossenen Rechner eine eindeutige IP-Adresse (z. B.
131.234.164.5) zugewiesen, wodurch gewährleistet wird, daß die Empfänger präzise
adressiert werden können. Eine detaillierte Beschreibung des TCP/IP-Protokolls findet
man in Comer (1998). Die Einordnung in das OSI-Referenzmodell (Open Systems Interconnections) wird detailliert in Tanenbaum (1992) beschrieben.
Das Internet ist die Basis für zahlreiche Dienste. Neben dem in dieser Arbeit relevanten
WWW sind vor allem Email (Electronic Mail) zum Austausch von Nachrichten, die als
Newsgroups oder auch Usenet bekannten Diskussionsforen, FTP (File Transport Protocol) zur Übertragung von Dateien und IRC (Internet Relay Chat) zur textbasierten Online Diskussion zu nennen. Bekannte, jedoch veraltete Dienste sind das Informationssystem WAIS (Wide Area Information System) und Gopher zur Übertragung einfacher
Textdokumente.
Alle Internetdienste arbeiten nach dem Client/Server-Prinzip, d. h. die Gesamtfunktion
eines Dienstes wird in zwei Bereiche aufgeteilt. Dabei bietet ein meist permanent mit
dem Internet verbundener Rechner, der Server, einen oder mehrere Dienste an, welche
von anderen Rechnern, den Clients, abgefragt werden. Zur Kommunikation zwischen
Client und Server benutzen die Dienste eigene Protokolle wie SMTP (Simple Mail
Transfer Protocol) für Email, NNTP (Network News Protocol) für Diskussionsforen und
HTTP (Hypertext Transfer Protocol) für das WWW, welche alle auf dem TCP/IPProtokoll basieren. Im Rahmen dieser Arbeit von Bedeutung ist das Hypertext Transfer
7
Protocol2. Gemäß dem Client/Server-Prinzip öffnet dabei der Webclient eine Verbindung zum Webserver, indem er über TCP/IP einen Port anwählt, an dem der Server auf
Anforderungen (Requests) wartet. Die Anforderungen setzen sich immer aus einer Methode (Method), einem Kopf (Header) mit zusätzlichen (Meta-)Informationen und optional einem mitgesendeten Objekt (Entity) zusammen. Die gebräuchlichsten Methoden
sind GET, mit der eine bestimmte Seite vom Server angefordert wird; HEAD, die den
Server auffordert, nur den HTTP-Header zurückzusenden; PUT, die das Gegenstück zur
GET-Methode darstellt und ein mitgesendetes Entity an den Server zur Speicherung
übergibt. Die im Header übermittelten Informationen kann man in folgende Kategorien
einteilen (vgl. Hajji 1998, S. 469-471):
-
Allgemeine (General) Header. Allgemeine Header können sowohl vom Server als
auch vom Client stammen. Typisch sind hier Date, Connection usw.
-
Anforderungs- (Request-) Header. Diese Header werden vom Client an den Server
gesendet. Mit ihnen identifiziert sich der Client und gibt beispielsweise an, welche
MIME-Typen (Multipurpose Internet Mail Extensions) er akzeptieren kann.
-
Entity-Header. Entity-Header beinhalten Meta-Informationen über das angeforderte
bzw. gesendete Objekt, wie z. B. Länge (Content-Length) oder Typ (ContentType).
Hat der Server eine Anforderung von einem Client erhalten, gibt er je nach Anfrage eine
bestimmte Antwort zurück, also z. B. die angeforderte Seite oder eine passende Fehlermeldung. Die Antwort ist dabei analog zu den Anfragen aufgebaut, enthält aber zusätzlich folgende Header:
-
HTTP-Version. Diese speziellen Rückgabecodes werden vom Client ausgewertet,
um herauszufinden, ob seine Anfrage erfolgreich war oder nicht.
-
Antwort- (Reply-) Header. Antwort-Header werden nur vom Server gesendet. Sie
identifizieren z. B. die Server-Software und geben weitere Informationen.
Damit der Server weiß, welches Objekt er zurückgeben soll, sind alle Ressourcen (z. B.
Dokumente, Grafiken usw.) im WWW durch sogenannte Uniform Resource Locator
2
Die folgenden Ausführungen beziehen sich auf HTTP/1.1, wie in Request for Comments (RFC) 2068
spezifiziert (siehe Fielding et al. 1999).
8
(URL) eindeutig adressierbar. Eine HTTP-URL setzt sich dabei wie folgt zusammen:
http://host [ ":" port ] [ abs_path ], wobei host für den Servernamen
steht, port den TCP/IP-Anschluß spezifiziert3 und abs_path das Verzeichnis und den
Namen des Objektes angibt (vgl. Berners-Lee 1994, S. 12f. und Berners-Lee et al. 1994,
S. 8).
Die offizielle Spezifikation von HTTP/1.1 kann nachgelesen werden in Fielding et al.
(1997) und Fielding et al. (1999). Eine eher anwendungsorientierte Einführung in HTTP
liefert Wong (1997).
Nachdem das Internet als Basis und die zugrundeliegenden Protokolle beschrieben wurden, wird nun genauer auf das World Wide Web an sich eingegangen. Seit seiner Entstehung im Jahre 1989 am CERN (Centre Européen pour la Recherche Nucléaire) hat
sich das WWW ständig weiterentwickelt. War das WWW ursprünglich noch ein rein
textbasiertes System (vgl. Ramm 1996, S. 8), so können heute durch die Etablierung
immer neuer Standards und durch die Weiterentwicklung der Webbrowser genannten
Webclients auch multimediale Informationen wie Bilder, Grafiken, Sound und Video
integriert werden. Zudem wurden Schnittstellen zu anderen Internetdiensten wie Email
oder FTP hinzugefügt (vgl. Münz/Nefzger 1998). Somit bietet das WWW mit seiner
einfachen Navigation und der grafischen Benutzeroberfläche gerade für Einsteiger eine
einfache Möglichkeit, am großen Informationsangebot des Internets zu partizipieren.
Das WWW setzt sich aus Millionen einzelner Webseiten zusammen, die über sogenannte Links miteinander verknüpft werden können. Mehrere zusammenhängende
Webseiten z. B. eines Autors oder eines Unternehmens werden als Website oder auch
Homepage bezeichnet (vgl. Ramm 1996, S. 4). Durch die Möglichkeit, mit eingebetteten Links innerhalb des Textes auf andere Webseiten zu verweisen oder auch innerhalb
eines größeren Dokumentes zu navigieren, verfolgt das WWW das Konzept des Hypertextes (siehe auch Nastansky et al. 1994, 332f.). Umgesetzt werden die Webseiten mittels der Seitenbeschreibungssprache HTML4 (Hypertext Markup Language). Ein solches
HTML-Dokument verfügt über einen strukturierten Aufbau und besteht aus mehreren
Elementen, die mit Hilfe von Etiketten (engl. Tags) kenntlich gemacht werden (vgl.
3
Beim HTTP-Protokoll wird 80 als Standardport benutzt.
4
Im Rahmen dieser Arbeit HTML 4.0
9
Maurer 1996, S. 5f). Grundsätzlich ist ein HTML-Dokument wie in Abb. 1 illustriert
aufgebaut.
<HTML>
<HEAD>
<TITLE> ... </TITLE>
</HEAD>
<BODY>
...
</BODY>
</HTML>
Abb. 1: Aufbau und Struktur von HTML-Dokumenten
Betrachtet man nur die HTML-Elemente HTML, TITLE, HEAD und BODY, erhält man
die Grundstruktur eines HTML-Dokumentes. Während im HEAD-Abschnitt Informationen zum Dokument wie Titel, Hintergrund usw. abgelegt werden, enthält der BODYAbschnitt den eigentlichen Inhalt der Webseite. Mit der Weiterentwicklung von HTML
entstanden auch neue Konzepte wie Framesets (Frames), Image Maps und Formulare,
die durch Vereinfachung der Navigation und Erweiterung der Funktionalität den Erfolg
des WWW entscheidend beeinflußt haben.
Um das WWW auch für Anwendungen wie z. B. Online-Banking oder Ecommerce nutzen zu können, wurden Programmierbarkeit und dynamische Konzepte notwendig. Hier
haben sich vor allem zwei Ansätze etabliert:
-
Mit CGI-Scripts (Common Gateway Interface), die auf dem Server ausgeführt werden, kann über ein WWW-Frontend auf eine im Hintergrund (Backend) liegende
relationale Datenbank zugegriffen werden (vgl. Hajji 1998, S. 569ff.).
-
JavaScript und Java-Applets basieren auf der plattform-unabhängigen Programmiersprache Java. Mit diesen Technologien können leistungsfähige Webapplikationen entwickelt werden, die auf den Webclients ausgeführt werden. Während JavaScript direkt in das HTML-Dokument eingebunden wird, müssen Java-Applets vor
ihrer Ausführung zunächst vom Server auf den Client geladen werden. Im Zusammenhang mit Java-Applets sind auch noch Java-Servlets zu erwähnen, die, wie der
Name schon andeutet, auf dem Webserver ausgeführt werden.
10
Aufgrund der eingesetzten Plattform Lotus Notes/Domino im untersuchten Unternehmen spielen CGI-Scripts in den folgenden Kapiteln keine Rolle. Auch andere Konzepte,
wie die Active Server Pages (ASP) von Microsoft, werden aus genanntem Grund nicht
berücksichtigt.
2.2 Suchmaschinen als ordnende Instanzen im WWW
Aufgrund der zentralen Bedeutung von Suchmaschinen für diese Arbeit werden in diesem Abschnitt die grundlegenden Technologien und Konzepte von Suchmaschinen betrachtet. Dazu wird zunächst die Geschichte von Suchmaschinen im Internet und WWW
beschrieben, bevor die verschiedenen Grundtypen von Suchmaschinen gegeneinander
abgegrenzt werden. Daraufhin wird detailliert auf die Architektur und die Vorgehensweise der für diese Arbeit relevanten Suchmaschinen eingegangen. Schließlich werden
auch die von Lotus speziell für Lotus Notes/Domino entwickelten Suchmechanismen
dargestellt.
2.2.1 Historische Betrachtung von Suchmaschinen
Vor der Einführung des WWW war neben Email und Newsgroups das Austauschen von
Dateien (FTP) einer der meist genutzten Dienste im Internet. Mit der steigenden Zahl an
FTP-Servern war ein Werkzeug notwendig geworden, welches die Server und die dort
gespeicherten Programme bzw. Dateien katalogisierte. Daher entwickelte Alan Emtage,
ein Student an der McGill University in Montreal, im Jahre 1990 mit Archie ein skriptbasiertes Werkzeug, welches FTP-Server im Internet aufsucht, deren Inhalt indiziert,
seine so erzeugte Datenbank auf Benutzeranfragen (engl. Query) hin durchsucht und die
Ergebnisse zurückgibt. Damit stellt Archie den ersten Suchdienst im Internet dar (vgl.
Sonnenreich/Macinta 1998, S. 1).
Die wachsende Popularität von Archie inspirierte Entwickler an der University of Nevada Systems Computing Services im Jahre 1993 dazu, Veronica (Very Easy RodentOrientated Netwide Index to Computerized Archives) zu entwickeln. Veronica war Archie sehr ähnlich und übertrug dessen Funktionalität auf einen anderen Internetdienst, in
diesem Falle Gopher. Später wurden auch Suchwerkzeuge für die übrigen im Internet
angebotenen Dienste entwickelt, wie z. B. DejaNews für die Diskussionsforen.
Mit der Einführung des WWW wurden andere, speziell an diesen Dienst angepaßte
Suchwerkzeuge erforderlich. Die ersten waren lokale Indexierer wie WAIS oder Glimp-
11
se, welche eine Volltextindizierung eines kompletten Webservers anlegen konnten. Fast
zeitgleich mit Glimpse tauchten auch die ersten Roboter im Web auf, die das WWW
automatisch durchsuchen und die besuchten Seiten an einen Indexer zur Aufnahme in
eine Datenbank weitergeben. Der erste dieser Roboter war der World Wide Web Wanderer. Ursprünglich dazu entwickelt, Webserver zu zählen, um die Größe und das
Wachstum des WWW zu dokumentieren, sammelte er kurz darauf die besuchten URLs
in einer Wandex genannten Datenbank, welche somit die erste Webdatenbank der Welt
darstellte. Suchmaschinen wie Excite, Altavista usw. funktionieren nach dem gleichen
Prinzip, wurden allerdings im Laufe der Jahre kontinuierlich weiterentwickelt. So wurden Funktionen wie Volltextindizierung der besuchten Seiten hinzugefügt, leistungsfähigere Suchanfragen implementiert sowie auch Sicherheitsaspekte berücksichtigt (vgl.
Sonnenreich/Macinta 1998, S. 1-13).
Auch für Intranets wurden mit wachsender Größe Suchmaschinen interessant. Da sie
zumeist auf den gleichen Standards wie das Internet und das WWW aufbauen, konnten
hier auch die oben beschriebenen Suchmaschinen eingesetzt werden. Aufgrund der heterogenen Umgebung, die in den meisten Intranets gegeben ist, weisen IntranetSuchmaschinen wie z. B. Verity oder Ultraseek erweiterte Funktionalitäten auf, um auch
lokale Dateisysteme und relationale Datenbanken durchsuchen und indizieren zu können.
Parallel zu diesen automatisch erzeugten Indexen etablierten sich manuell zusammengestellte Webverzeichnisse5, auch Kataloge genannt. Anbieter von Webinhalten müssen
dabei ihre Seiten bei dem Verzeichnisdienst anmelden. Die so erstellten Verzeichnisse
beinhalten technisch bedingt einen wesentlich kleineren Datenbestand. Dafür liefern sie
meist qualitativ bessere Suchergebnisse, da die Erstellung der Indexe von Menschen
und nicht von automatischen Indexern vorgenommen wird. Auch sogenannte Linksammlungen und FAQs (Frequently Asked Questions) können zu den Katalogen gezählt
werden.
Leistungsfähigere Hardware und effizientere Algorithmen ermöglichen es, immer mehr
Seiten im WWW in immer kürzeren Zeitintervallen zu indizieren. Trotzdem können die
Suchmaschinen nicht mit dem Wachstum des Webs Schritt halten. Wie in Abb. 2 zu
5
Wie z. B. der populäre Verzeichnisdienst Yahoo (http://www.yahoo.com)
12
sehen, erfassen die heutigen Suchmaschinen nur einen Bruchteil des World Wide Webs.
Seit 1995 existieren daher sogenannte Meta-Crawler oder Suchmaschinen 2. Ordnung6.
Diese richten die Suchanfragen parallel an mehrere der großen Suchmaschinen und fassen die Ergebnisse, sogenannte Trefferlisten, wieder zusammen, um auf diese Weise
eine größere Abdeckung des WWW zu erzielen.
40%
30%
20%
10%
0%
HotBot
AltaVista Northern
Light
Excite
Infoseek
Lycos
Abb. 2: Suchmaschinen-Abdeckung des WWW (Quelle: Lawrence/Giles 1998)
In etwa zeitgleich begann mit den verteilten Systemen eine weitere Entwicklungsrichtung (vgl. Sander-Beuermann 1998, S. 180). Verteilte Systeme machen sich den modularen Aufbau der Suchmaschinen zu Nutzen. Sie nehmen eine strikte Aufgabentrennung
zwischen dem Sammeln der Informationen und der Aufnahme der Informationen in
einer Datenbank (Index) vor. Auf diese Weise können mehrere Roboter gleichzeitig das
Web durchsuchen, deren Daten in einem getrennten Prozeß in den Index aufgenommen
werden. Führt man die Idee der Aufgabenteilung solcher einfach verteilter Systeme
konsequent weiter fort, kann man sich auch ein mehrfach verteiltes System mit mehreren Sammlern und mehreren Datenbanken vorstellen (siehe Abb. 3 auf Seite 13). Eine
detaillierte Beschreibung anhand der frei verfügbaren Suchmaschine Harvest findet der
interessierte Leser in Borggraefe (1999).
Aus der oben beschriebenen Geschichte der Suchmaschinen lassen sich nach SanderBeuermann (1998, S. 180) die drei folgenden Tendenzen ableiten:
1. Mit der Einführung von Robotern entwickelten sich aus lokalen Sammelprozessen
globale Strukturierungsversuche.
6
Z. B. MetaCrawler (http://www.metacrawler.com) oder MetaGer (http://meta.rrzn.uni-hannover.de)
13
2. Um das steigende Angebot von Suchmaschinen besser zu nutzen, haben sich MetaSuchdienste etabliert.
3. Um die wachsende Datenflut zu bewältigen, werden Konzepte wie verteilte Systeme
notwendig.
Die gerade beschriebene Entwicklung stellt jedoch noch nicht die Grenzen der Forschungen dar. Die Trefferlisten der Suchmaschinen erster und zweiter Ordnung sind
meist sehr groß und enthalten viele irrelevante Links. So wird ein am Gartenanbau interessierter Benutzer kaum Informationen zum Politiker „Kohl“ suchen. Momentan sind
daher Bemühungen im Gange, Suchmaschinen der 3. Generation zu verwirklichen. Diese setzen auf Meta-Crawlern auf, um spezielle Indizes für bestimmte Interessengebiete
zu entwickeln7.
Datenbank
3
Datenbank
2
Datenbank
1
Spider 1
Spider 2
Spider 3
Spider 4
Spider 5
Datenquellen im WWW und Intranet
Abb. 3: Aufbau von mehrfach verteilten Systemen
7
Eine detaillierte Beschreibung findet man in Sander-Beuermann (1998), S. 181ff.
14
2.2.2 Abgrenzung des Begriffs Suchmaschine
Im vorangegangenen Abschnitt wurden bereits mehrere Suchdienste und deren Konzepte vorgestellt. Die riesige Anzahl an Suchdiensten im WWW8 läßt sich anhand ihrer
Vorgehensweise in folgende Kategorien einteilen (vgl. Sullivan 1999a):
-
Spezielle Suchdienste: Diese haben sich auf einzelne Bereiche des Internets spezialisiert (z. B. Archie auf FTP oder Dejanews auf Newsgroups). Daher spielen sie in
den weiteren Betrachtungen keine Rolle.
-
Verzeichnisdienste/Kataloge: Das wichtigste Merkmal von Verzeichnisdiensten
(wie z. B. Yahoo) ist, daß sie nicht voll automatisch erstellt werden. Das heißt, die
darin aufgeführten Webseiten werden nicht durch einen Roboter gesammelt, sondern von den jeweiligen Autoren bzw. Administratoren dem Verzeichnisdienst gemeldet, wo diese dann manuell kategorisiert und eingestuft werden.
-
Suchmaschinen: Suchmaschinen (z. B. Altavista oder Hotbot) durchsuchen mit Hilfe
von Robotern (auch Spider, Crawler oder Gatherer genannt9) automatisch das Web.
Dabei gehen sie von Ausgangsseiten aus, verfolgen alle weiterführenden Links und
nehmen sie dabei in einen Index auf. Aus diesem Index werden dann die Suchergebnisse generiert.
-
Hybride Suchmaschinen: Einige Verzeichnisdienste greifen auf Wunsch auch auf
den Index einer Suchmaschine zurück (z. B. arbeitet Yahoo mit Altavista zusammen). Andersherum erstellen Suchmaschinen auch durch Reviews und Ratings der
indizierten Webseiten eigene Verzeichnisse (siehe auch Abschnitt 4.2.1).
-
Suchmaschinen 2. Ordnung: Diese auch Meta-Crawler genannten Suchmaschinen
durchsuchen nicht selbst das Web, sondern geben die Suchanfragen parallel an mehrere der großen Suchmaschinen weiter und fassen die Ergebnisse anschließend zusammen.
8
Eine umfassende Liste ist in Anhang 9.1.1 zu finden.
9
Im folgenden wird in Anlehnung an die Terminologie der im untersuchten Unternehmen eingesetzten
Suchmaschinen Verity nur noch der Begriff Spider benutzt (vgl. Deutsche Bank 1999, S. 5).
-
15
Verteilte Systeme: Durch strikte Aufgabenteilung in Spider und Indexer werden
Suchmaschinen effizienter. Je nach Grad der Aufgabenteilung wird zwischen einfach und mehrfach verteilten Systemen unterschieden (vgl. auch Abschnitt 2.2.1).
Im Fokus dieser Arbeit liegt die Problematik, die im Zusammenhang mit den automatischen Robotern der Suchmaschinen besteht. Verzeichnisdienste und die speziellen
Suchdienste werden daher nicht weiter berücksichtigt. Auch hybride und MetaSuchmaschinen sowie verteilte Systeme werden nicht gesondert betrachtet, sondern
unter dem Begriff Suchmaschinen zusammengefaßt, da die in Kapitel 3 untersuchten
Probleme die gleichen wie bei Suchmaschinen sind. Auf die Vorgehensweise von MetaSuchmaschinen wird im folgenden Abschnitt jedoch kurz eingegangen10, da deren Konzept in den Kapiteln 4 und 5 noch eine Rolle spielt. Wie anhand der Liste in Anhang
9.1.1 zu sehen, ist die Anzahl der Suchmaschinen im WWW sehr groß und wächst immer weiter. Da es unmöglich wäre, im Rahmen dieser Arbeit alle Suchmaschinen zu
untersuchen, beschränken sich die Ausführungen und Analysen auf eine ausgewählte
Anzahl der größten bzw. meist besuchten Suchmaschinen (in Tabelle 1 durch fette
Schrift gekennzeichnet).
Suchmaschine
URL
Suchmaschine
URL
Altavista
www.altavista.com
Infoseek
www.infoseek.com
Ask Jeeves
www.askjeeves.com
Looksmart
www.looksmart.com
AOL Netfind
www.aol.com/netfind
Lycos
www.lycos.com
Direct Hit
www.directhit.com
MSN
www.msn.com
Excite
www.excite.com
Netscape
www.netscape.com
Google
www.google.com
Northern Light
www.northernlight.com
GoTo
www.goto.com
Search.com
www.search.com
Hotbot
www.hotbot.com
Snap
www.snap.com
Inktomi
www.inktomi.com
Webcrawler
www.webcrawler.com
Tabelle 1: Die größten und populärsten Suchmaschinen (Quelle: Sullivan 1999)
10
Eine detailliertere Beschreibung findet man in Sander-Beuermann (1998).
16
2.2.3 Architektur und Vorgehensweise von Suchmaschinen
Um im nachfolgenden Kapitel eine strukturierte Problemanalyse vornehmen zu können,
ist es wichtig, zunächst den Aufbau und die Vorgehensweise von Suchmaschinen detailliert zu beschreiben und so eine genaue Zuordnung von Ursache und Problem vornehmen zu können. Dazu werden im folgenden die wesentlichen Komponenten von
Suchmaschinen differenziert betrachtet und deren genaue Funktionsweise aufgezeigt.
Alle gemäß dem vorangegangenen Abschnitt definierten Suchmaschinen lassen sich in
drei Hauptkomponenten differenzieren (vgl. Sullivan 1999a und Sander-Beuermann
1996): Den Spider, der das Web automatisch durchsucht, einen Indexer, welcher alle
gefundenen Webseiten indiziert und in eine Datenbank aufnimmt und die Suchmaschinensoftware, die auf Suchanfragen hin den Index durchsucht und eine nach bestimmten
Regeln generierte Trefferliste zurückgibt (vgl. auch Abb. 4).
Der Indexer indiziert die
gefundenen Seiten und führt
ein Update der Database aus
Indexer
3
Der Spider
gibt neue und
geänderte
Seiten an den
Indexer
2
Suchanfrage
Index
Database
Benutzer
Spider
Der Spider "crawlt"
durch Web und
Intranet und
untersucht die
gefundenen Seiten
auf Änderungen
Suchergebnisse
als Trefferliste
1
Web- und Intranet-Sites
Abb. 4: Vorgehensweise von Suchmaschinen
17
Der Spider geht bei seiner Suche durch das WWW von einer Startseite aus. Diese besteht aus einer Liste von URLs, welche der Spider nacheinander aufsucht. Dabei fordert
der Spider vom entsprechenden Webserver zunächst nur den HTTP-Header an. Anhand
der darin enthaltenen Meta-Informationen wird durch einen Abgleich mit der Datenbank
ermittelt, ob es sich um eine neue oder seit dem letzten Besuch geänderte Seite handelt
(vgl. Abb. 4 [1]). Ist dies der Fall, schickt der Spider die Seite an den Indexer zur späteren Bearbeitung und verfolgt alle darin enthalten URLs weiter. Dieser Vorgang wird so
lange fortgesetzt, bis eine vorher festgelegte Suchtiefe erreicht wird oder der Spider auf
eine Seite trifft, die keine neuen Links mehr enthält bzw. deren weitere Verfolgung dem
Spider untersagt wird (vgl. dazu Abschnitt 4.3).
Die von dem Spider gesammelten Webseiten werden im nächsten Schritt von einem
Indexer weiterverarbeitet und in eine Datenbank aufgenommen, bzw. bei Änderungen
wird diese aktualisiert (vgl. Abb. 4 [2]). Dabei werden aus Gründen des Speicherplatzes
nicht die kompletten Webseiten gespeichert, sondern nur bestimmte Komponenten wie
z. B. Titel, Meta-Tags und natürlich die zugehörige URL. Manche Suchmaschinen
nehmen zudem noch eine Volltextindizierung der Webseiten vor.
Die so erstellte Webdatenbank bildet die Basis für die eigentliche Suchmaschinensoftware. Über ein Suchinterface kann der Benutzer Suchanfragen eingeben. Die Software
durchsucht daraufhin die Datenbank nach den Stichwörtern und erzeugt eine Trefferliste, die an den Benutzer zurückgegeben wird (vgl. Abb. 4 [3]). Die Reihenfolge der angezeigten URLs wird dabei nach Gewichtung und Relevanz, bezogen auf die Suchanfrage, sortiert (engl. Ranking).
Auch wenn die Suchmaschinen vom Aufbau und von der grundlegenden Vorgehensweise her identisch sind, so unterscheiden sie sich doch in ihrer Leistungsfähigkeit, ihrem Funktionsumfang und den unterstützten Standards. Als Beispiele seien hier die Anzahl der am Tag vom Spider besuchten Seiten, die Unterstützung von HTMLFunktionalitäten wie Image-Maps und Framesets sowie die möglichen Parameter zur
Suchanfrage und vor allem die Vorgehensweise bei dem bereits erwähnten Ranking zu
nennen (vgl. Sullivan 1999c).
18
2.2.4 Spezielle Suchmechanismen für Lotus Notes/Domino
Informations-, Content- und Knowledge-Management gehören zu den Haupteinsatzfeldern von Lotus Notes/Domino11. Daher wurden von Lotus mehrere speziell auf
Notes/Domino abgestimmte Suchmechanismen entwickelt. Im einzelnen sind dies:
-
Volltextindizierung und –suche der Notes-Datenbanken
-
Search Site Database
-
Domino R5 Domain Search
-
Lotus Domino Extended Search
Jede Notes-Datenbank bietet die Funktion zur Volltextindizierung und zur Suche in diesem Volltextindex. Die Suche beschränkt sich aber dabei auf die jeweils geöffnete Datenbank, eine parallele Suche in mehreren Datenbanken ist auf diese Weise nicht möglich. Um mehr als eine Datenbank gleichzeitig zu durchsuchen, kann eine spezielle Search Site Database auf einem Domino-Server installiert werden, mit deren Hilfe mehrere Datenbanken auf diesem Server indiziert und durchsucht werden können. Ein entsprechendes Template wird bei jedem Lotus Domino-Server mitgeliefert.
Seit der Release 5 von Domino ist es zusätzlich möglich, auf einem Domino-Server
einen Domain-Indexer als speziellen Task laufen zu lassen. Mit dieser Domain Search
genannten Lösung können alle Datenbanken auf allen Domino-Servern einer DominoDomaine indiziert werden. Darüber hinaus bietet Lotus mit Domino Extended Search
eine zusätzliche Lösung an, mit der neben mehreren Domino-Domainen auch relationale Datenbanken und Webindizes durchsucht werden können.
Die beschriebenen Suchmechanismen bieten somit einen modularen Aufbau, der verschiedensten Anforderungen des Informations- und Knowledge-Management genügt.
Es wird damit jedoch keine Lösung angeboten, um die eigenen Webseiten externen
Suchmaschinen zugänglich zu machen. Da dieser Aspekt eine der Hauptzielsetzungen
dieser Arbeit darstellt, werden diese speziellen Suchmechanismen im weiteren Verlauf
nicht mehr berücksichtigt. Zusätzliche Informationen zu diesem Thema findet der interessierte Leser in Collins et al. (1999, S. 282-285), Florio (1999) und Lotus Development
(1998).
11
Im folgenden wird die Firmenbezeichnung Lotus vereinfachend weggelassen.
19
2.3 Lotus Notes/Domino R5
Da der Schwerpunkt dieser Arbeit auf Suchmaschinen und ihre Integration in eine auf
Notes/Domino basierende Applikation liegt, beziehen sich die folgenden Ausführungen
hauptsächlich auf die Architektur des Domino-Servers, vor allem in seiner Funktionsweise als Webserver. Zudem wird eine Abgrenzung der Begriffe Notes und Domino
vorgenommen sowie die wesentlichen neuen Designelemente der Release 5 vorgestellt.
Grundlegende Begriffe wie Groupware sowie technische Merkmale und Komponenten
(z. B. Notes-Datenbank, Dokument, Maske, Ansicht, Agent usw.) der Plattform
Notes/Domino werden dabei als bekannt vorausgesetzt. Der interessierte Leser wird auf
Nastansky (1993) und Ott/Nastansky (1997) sowie auf die Werke Dierker/Sander
(1998), Axt/Hertel/Wagner (1999) und Denning et al. (1998) verwiesen12.
Seit der ersten Release im Jahre 1989 hat Notes sich von einer reinen GroupwarePlattform hin zu einer Plattform für Intranet- und Internetapplikationen entwickelt. Vor
allem mit der zunehmenden Integration von Webstandards seit der Version 4.0 begann
ein Synergieprozeß von Groupware-Konzepten und Internet-Technologien, der mit der
Einführung eines speziellen Webservers namens Domino in der Version 4.5 seinen bedeutendsten Schritt machte (vgl. Florio 1999a). Später wurde aus Gründen des Marketing der komplette Server Domino genannt, während der Client die ursprüngliche Bezeichnung Notes beibehielt (vgl. Daibenzeiher et al. 1997, S. 37-40).
Für die Funktionsweise des Domino-Servers als Webserver sind zwei Serverprozesse
verantwortlich (vgl. Axt/Hertel/Wagner 1999, S. 532ff.), der HTTP-Servertask (front
end) und die Domino Web Engine (back end). Die HTTP-Serverkomponente verhält
sich dabei wie ein gewöhnlicher Webserver (z. B. Apache) und wartet auf Anfragen von
Webclients. Verweist die angeforderte URL auf eine gewöhnliche HTML-Datei, wird
diese direkt zurückgegeben. Bestimmte URL-Anfragen (siehe auch Abschnitt 3.2.1)
werden von dem HTTP-Task allerdings als ein spezieller Befehl erkannt, der für den
Zugriff auf ein Notes-Element bestimmt ist. Dieser Befehl wird an die Domino Web
Engine weitergeleitet, die den Befehl interpretiert und das angeforderte Daten- oder
Gestaltungselement der entsprechenden Datenbank aufruft. Daraus generiert die Domi-
12
Mit Ausnahme von Axt/Hertel/Wagner (1999) behandeln die angegebenen Literaturquellen noch die
vorige Version 4.x von Notes/Domino.
20
no Web Engine dynamisch ein HTML-Script, welches über den HTTP-Server als
Webseite an den Client zurückgegeben wird (siehe hierzu auch Abb. 5).
Domino
HTTP-Client
(Browser oder
Suchmaschine)
GET-URL
HTTP-Server
Domino
Web Engine
HTML etc.
Notes C++ API
Notes-Kernel
HTML,
GIF, CGI
etc.
Notes
Datenbanken
Abb. 5: Architektur des Domino-Servers
Mit der Release 5 von Notes/Domino ist die Integration von Internet-Technologien und
–Standards weiter fortgeschritten. Vor allem mit der stärkeren Implementierung von
Java-Applets ist es nun möglich, Notes-Elemente wie z. B. Ansichten näher am NotesOriginal darzustellen (vgl. Axt/Hertle/Wagner 1999, S. 330). Zudem wird durch das
Ausführen der Applets auf den Clients ein Gewinn an Performance erzielt und die Serverlast verringert.
Auch der Notes-Client hat einige Veränderungen aufzuweisen. Neben der neuen grafischen Benutzeroberfläche ist vor allem die Aufteilung des Clients in drei aufgabenspezifische Komponenten zu erwähnen. Neben dem gewohnten Notes-Client stehen nun
zusätzlich der Domino Designer und der Domino Administrator mit jeweils eigenen
Benutzeroberflächen zur Verfügung. Im Rahmen dieser Arbeit sind vor allem die mit
dem Domino Designer neu hinzugekommenen Designelemente interessant, da sie vorrangig auf die Entwicklung von Webapplikationen abzielen. Im folgenden werden daher
kurz die R5-Designelemente Seite (Page), Gliederung (Outline) und Rahmengruppe
21
(Frameset)13 vorgestellt, die in den anschließenden Kapiteln noch eine zentrale Rolle
spielen. Eine komplette Liste aller Neuerungen und eine detailliertere Beschreibung
findet der interessierte Leser in Collins et al. (1999), S. 175ff. und Burch (1999). Eine
Übersicht über die Programmiermöglichkeiten liefert Mann (1999).
Seiten kann man als Masken ohne Felder beschreiben. Sie dienen dementsprechend der
Anzeige von Informationen und sind nicht wie Masken zur Dateneingabe geeignet. Ansonsten weisen sie alle Funktionalitäten wie Images, Dateianhänge, Aktionsschaltflächen etc. auf. Auch können sie als Container für andere Notes-Elemente wie z. B. Ansichten oder Navigatoren benutzt werden. Der Haupteinsatz von Seiten ist daher zum
einen als Ersatz für die $$ViewTemplate-Maske, zum anderen wegen ihrer guten Layout-Möglichkeiten als Startseiten für Webapplikationen zu sehen.
Rahmengruppen dienen zur Abbildung der in Abschnitt 2.1 beschriebenen HTMLFramesets in Notes. Die Arbeitsfläche wird dabei in mehrere definierbare Bereiche aufgeteilt, denen dann explizit Seiten, Ansichten, Masken, Applets oder URLs zugewiesen
werden können.
Gliederungen ermöglichen es, eine hierarchische Struktur von Links und NotesElementen für eine Site zu erstellen. Sie verknüpfen dabei das dynamische Konzept von
Ansichten mit dem graphischen Layout von Navigatoren. Daher eignen sie sich vor allem für sogenannte Site Maps und Navigationsframes.
2.4 NetFicient Release 2
Ursprünglich stellte NetFicient ein Werkzeug zum Erstellen von Webseiten im Internet
und Intranet mit integriertem Redaktionsworkflow dar. Schnell wurde das Produkt um
weitergehende Funktionen wie ein Newspanel ergänzt. Um aber der wachsenden Informationsflut und der zunehmenden Komplexität gerecht zu werden, sind innovative
Technologien notwendig wie z. B. der Wandel vom Informations- zum Knowledge Management. Um diesen Prozeß zu unterstützen, wird NetFicient in der nächsten Release 2
zu einer Knowledge Management Plattform ausgebaut, wobei die Publishing Kompo-
13
Um Verwechslungen vorzubeugen, werden für die Notes-Designelemente die deutschen Bezeichnun-
gen verwendet, während im Webkontext auf die englischen Begriffe zurückgegriffen wird.
22
nente ein zentraler Bestandteil der NetFicient Familie darstellt, die demnächst aus folgenden Modulen bestehen soll (vgl. Deutsche Bank AG 1999b, S. 15ff):
-
NetFicient.Publishing stellt das Basismodul für den Aufbau eines professionellen
I*nets dar.
-
NetFicient.Knowledge soll den bereits angesprochenen Wandel vom Informationszum Knowledge-Management unterstützen (vgl. Abb. 6).
-
NetFicient.Solutions garantiert eine unternehmensweit einfache und sichere Kommunikation.
-
NetFicient.eBusiness ist für die Abwicklung der elektronischen Bestell- und Zahlungsvorgänge zuständig.
Knowledge Management
Expertise
Ich weiß nicht, wer mir helfen
kann!
Quality
NetFicient
Ich habe eine Information,
doch wie gut ist sie wirklich?
Collaboration
Wie bringe ich Kollegen und
Dokumente in einen Kontext,
um damit Aktionen abzuleiten?
Organization
Discovery
Ich weiß, was ich suche, aber
ich kann es nicht finden!
Warum bekomme ich so viele
Informationen?
Abb. 6: Knowledge Management mit NetFicient
Da die korrekte Erfassung und Indizierung der mit NetFicient erstellten Web- und Intranetseiten im Zentrum der Betrachtungen steht, beziehen sich die Ausführungen in den
nachfolgenden Kapiteln hauptsächlich auf die Publishing-Komponente. Aber auch die
im Bereich des Knowledge Managements (vgl. Deutsche Bank AG 1999b, S. 6ff.) mit
NetFicient adressierten Problemstellungen (siehe Abb. 6) werden zum Teil durch eine
verstärkte Integration von Suchmaschinen unterstützt. So wird das Auffinden von Informationen (Discovery) durch ein leistungsfähiges Suchinterface erleichtert. Zudem
werden Konzepte entwickelt, die zum einen die Fülle der Informationen reduzieren
23
(Organization) und zum anderen die Bewertung der gefundenen Informationen (Quality) vereinfachen.
Aufgrund der Komplexität der Aufgabenbereiche ist es nicht immer möglich und auch
nicht sinnvoll, sich alle Informationen selber zu beschaffen. Oft ist es einfacher und
schneller, einen entsprechenden Experten zu Rate zu ziehen. In einem globalen Unternehmen wie der Deutschen Bank AG ist es daher wichtig, daß geeignete Experten jederzeit leicht zu ermitteln sind (Expertise). Da diese Thematik nicht unmittelbar mit der
Integration von Suchmaschinen in Beziehung steht, wird sie im weiteren Verlauf nicht
weiter verfolgt. Auch die in Abb. 6 beschriebene Collaboration spielt im Zusammenhang mit der in dieser Arbeit verfolgten Zielsetzung keine Rolle.
2.5 Technologische und konzeptionelle Rahmenbedingungen
In diesem abschließenden Abschnitt werden die eingesetzte Hard- und Software beschrieben, die als technologische Randbedingungen in den anschließenden Kapiteln
berücksichtigt werden müssen. Auch wird ein Blick auf einige Anforderungen an NetFicient geworfen, welche die konzeptionellen Randbedingungen für diese Arbeit darstellen.
Wie bereits beschrieben, wird als Plattform für NetFicient R2 Lotus Notes/Domino R5
zum Einsatz kommen. Alle in dieser Arbeit vorgenommenen Untersuchungen beziehen
sich dabei auf die Version 5.0. Auf der Client-Seite soll der proprietäre Notes-Client
durch einen universellen Webbrowser abgelöst werden. Im untersuchten Unternehmen
kommt hier auf Windows-Basis der Netscape Navigator in der Version 4.x, bei OS/2Clients momentan noch die Version 2.1 zum Einsatz. Für die in dieser Arbeit durchgeführten Tests wurde der Netscape Navigator 4.5 verwendet. Die interne Suchmaschine
dbsearch des untersuchten Unternehmens basiert auf der Suchsoftware von Verity 97,
mit der auch die Verifizierung des Konzeptes im abschließenden Proof of Concept
durchgeführt wird. Für Tests im Vorfeld wird die frei verfügbare Software Harvest in
der Version 1.4 sowie Testversionen der Suchwerkzeuge Phantom der Firma Maxum
und Altavista Discovery benutzt.
Neben der verstärkten Integration von Suchmaschinen wurden in der Spezifikation von
NetFicient R2 weitere Kernanforderungen formuliert. An dieser Stelle seien aber nur die
24
Punkte genannt, die für die Thematik dieser Arbeit relevant sind14. Dazu gehören, wie
die anschließende Problemanalyse zeigt, die Unterstützung von Mehrsprachigkeit, Multikontext und Multiframefunktionalität.
Für ein globales Unternehmen, wie es die Deutsche Bank AG darstellt, ist es von großer
Wichtigkeit, daß die vorhandenen Informationen in allen erforderlichen Sprachen dargestellt werden können. Das bedeutet zum einen, daß jedes Dokument in mehreren
Sprachen vorliegen muß, zum anderen sollte auch automatisch die gewählte Sprache
(wie z. B. Muttersprache oder Englisch) angezeigt werden.
Die Multiframefunktionalität umfaßt zwei Aspekte. Zunächst soll es, wie der Name
schon sagt, möglich sein, mehrere Navigationsframes auf mehreren Ebenen darzustellen
(Frame in Frame). Gleichzeit soll der Inhaltsframe so in die Lesezeichen (Bookmarks)
eines Browsers aufgenommen werden können, daß bei wiederholten Aufruf sowohl der
gewünschte Inhalt als auch die entsprechende Navigation erscheinen.
Mit Multikontext ist gemeint, daß ein Inhaltsframe in verschiedenen Websites darstellbar ist. Dabei soll der Inhalt unter verschiedenen Themenbereichen (Kontext) zu finden
sein und auch mit unterschiedlicher Gültigkeitsdauer oder ähnlichen Kriterien versehen
werden können.
14
Eine komplette Liste der Anforderungen ist in Deutsche Bank (1999a) zu finden.
Problemanalyse
25
3 Problemanalyse
Im vorangegangenen Kapitel wurde ausführlich die Vorgehensweise von Suchmaschinen beschrieben und näher auf die dabei relevanten Technologien eingegangen. Bei dem
Zusammenspiel dieser differenten Konzepte kommt es zwangsläufig zu Problemen. Ziel
dieses Kapitels ist es nun, die auftretenden Probleme einer eingehenden Analyse zu unterziehen. Um die beobachteten Probleme präzise ihrer Ursache zuordnen zu können,
ist es notwendig, den Gesamtkontext in eindeutig abgegrenzte Bereiche aufzuteilen.
Dazu werden zunächst die einzelnen Technologien separat im Zusammenhang mit
Suchmaschinen untersucht, um daran anschließend die bei der Synthese der verschiedenen Bereiche entstehenden Probleme zu analysieren. Gemäß dieser Vorgehensweise
werden in diesem Kapitel die folgenden abgegrenzten Problembereiche behandelt:
-
Die der Funktionsweise des Spiders zugrundeliegenden Web-Technologien,
-
Lotus Domino als eingesetzter Webserver,
-
die Suchmaschinensoftware an sich sowie
-
konzeptionell bedingte Probleme, die durch die definierten Rahmenbedingungen
von NetFicient gegeben sind.
Dabei wird zunächst in der Theorie dargestellt, welche Problemstellungen in den einzelnen Bereichen gegeben sind und wie sich diese auch in der Praxis auswirken.
3.1 Webtechnologien
Mit der Publishing-Komponente von NetFicient werden die Informationen sowohl im
Intranet als auch im Internet für den Zugriff von Webclients zur Verfügung gestellt, so
daß neben den Webbrowsern auch die Spider der Suchmaschinen darauf zugreifen können. Die diesem Prozeß zugrundeliegenden Webtechnologien werden in diesem Abschnitt auf Schwachstellen im Zusammenhang mit Suchmaschinen hin untersucht. Dazu
gehören vor allem das HTTP-Protokoll, die Seitenbeschreibungssprache HTML sowie
auf Java basierende dynamische Konzepte.
3.1.1 Das Hypertext Transport Protocol
Der Spider verhält sich bei seiner Suche durch das WWW bzw. Intranet wie ein Webclient. Dabei fordert er mittels einer GET-Anforderung von dem Webserver den jeweili-
Problemanalyse
26
gen HTTP-Header an. Mit Hilfe der Informationen in diesem Header wird ein Abgleich
mit dem Index der Suchmaschine durchgeführt, um neue Seiten bzw. Änderungen an
schon erfaßten Seiten festzustellen. Die folgenden HTTP-Header-Methoden spielen
dabei eine entscheidende Rolle:
-
Last-Modified: Dieser Entity-Header gibt an, wann die angeforderte Seite zuletzt
modifiziert wurde. Wird dieser Header nicht korrekt gesetzt, kann es zu zwei unterschiedlichen Fehlern kommen. Wenn der Webserver dieses Datum nicht auf dem
aktuellen Stand hält, können Änderungen vom Spider nicht identifiziert werden, und
somit wird auch der Index nicht aktualisiert. Des weiteren bewirken fehlerhafte oder
gar nicht gesetzte Werte (z. B. „unknown“), daß die entsprechenden Seiten bei jedem Durchlauf des Spiders als geändert klassifiziert und somit neu indiziert werden.
Dadurch wird eine erhöhte Belastung sowohl des Webservers als auch der Suchmaschine verursacht.
-
Expires: Mit Hilfe dieses Entity-Headers kann man ein „Verfallsdatum“ angeben,
an dem die Informationen der Webseite nicht mehr relevant sind. Bei dynamisch
generierten Inhalten geben jedoch viele Webserver für diesen Wert das aktuelle
Datum zurück. Suchmaschinen, die diesen Header interpretieren, nehmen derartige
Seiten dann nicht in ihren Index auf.
-
If-Modified-Since: Mit der Einführung von HTTP/1.1 wurde das Hypertext
Transport Protocol um einige Funktionen und Eigenschaften erweitert. Eine dieser
Erweiterungen ist die des „Conditional Requests“, wie in Fielding et al. (1999, S.
53) nachzulesen ist: „The semantics of the GET method change to a "conditional
GET" if the request message includes an If-Modified-Since, If-Unmodified-Since,
If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the entity be transferred only under the circumstances described by the
conditional header field(s).“ Gerade die If-Modified-Since Methode stellt für
die Suchmaschinen eine Möglichkeit dar, unveränderte Seiten direkt mit der Anforderung durch den Spider auszugrenzen und somit die Netzwerklast zu mindern und
die Suchmaschine zu entlasten. Voraussetzung für diese Vorgehensweise wäre jedoch, daß dieses Datum genau wie das Last-Modified Datum korrekt vom
Webserver verarbeitet wird.
Problemanalyse
27
Nachdem die potentiellen Problembereiche vorgestellt wurden, gilt es nun zu untersuchen, wie relevant die einzelnen Punkte in der Praxis sind. Dazu muß kontrolliert werden, wie der Domino-Server, genauer der HTTP-Server Task und die Domino Web Engine, mit diesen HTTP-Methoden umgeht. Da dies vom Kontext her eher in das Kapitel
3.2 paßt, sei an dieser Stelle nur erwähnt, daß der Domino-Server für das LastModified Datum je nach Element meist nicht den richtigen Wert, sondern entweder
nichts oder das aktuelle Datum zum Zeitpunkt der Anfrage der Seite zurückgibt. Ähnliches gilt auch für das Expires Datum, so daß es in beiden Fällen zu den oben geschilderten Auswirkungen kommen kann und somit in Kapitel 4 diese Problematik berücksichtigt wird. Eine genauere Betrachtung der Problematik Domino-Server und HTTPHeader folgt dann in Abschnitt 3.2.1, der sich explizit mit Notes/Domino beschäftigt.
Wird das Last-Modified Datum nicht korrekt zurückgegeben, kommt es dementsprechend auch zu Problemen mit der If-Modified-Since Methode. Da eine Lösung für
das Last-Modified Datum gleichzeitig das Funktionieren der If-Modified-Since
Methode garantiert, wird diese nicht weiter explizit betrachtet.
3.1.2 Hypertext Markup Language
Als Seitenbeschreibungssprache im WWW und im Intranet hat sich HTML etabliert.
Wie in Abschnitt 2.1 vorgestellt, ist der Funktionsumfang von HTML bis zu der hier
untersuchten Version 4.0 stark angestiegen. Daher gilt es in diesem Abschnitt zu analysieren, welche der HTML-Funktionen von Suchmaschinen unterstützt werden und welche nicht oder nur teilweise verstanden werden. Der Schwerpunkt der Untersuchungen
liegt hier vor allem auf den Auswirkungen im Suchvorgang, die sich durch diese Inkompatibilitäten ergeben. Berücksichtigt werden dabei in diesem und den folgenden
Kapiteln lediglich die am meisten genutzten Suchmaschinen (vgl. Abschnitt 2.2.2). Zudem wird die im Intranet der Deutschen Bank AG eingesetzte Suchmaschine dbsearch,
die auf Verity basiert (vgl. Deutsche Bank AG 1999, S. 8), in die Betrachtung mit einbezogen. Wie in Sullivan (1999c) zu sehen, werden die meisten HTML-Funktionen von
den Suchmaschinen unterstützt. Probleme ergeben sich vor allem mit Framesets, Image
Maps und JavaScript (vgl. Tabelle 2).
Framesets werden im WWW immer beliebter, da mit ihrer Hilfe die Navigation innerhalb einer Website oder Homepage auf einfache Weise realisiert werden kann. Wie
Webbrowser älterer Generationen unterstützen jedoch viele Suchmaschinen diese
Problemanalyse
28
Funktion nicht oder nur teilweise. So können, wie in Tabelle 2 zu sehen, von den hier
betrachteten Suchmaschinen immerhin die Hälfte nicht mit Framesets umgehen. Aber
auch wenn die Suchmaschine mit der Hilfe von Framesets erstellte Webseiten durchsuchen kann, kommt es, wie im Verlauf dieses Abschnitts erläutert wird, häufig zu Folgeproblemen. Daher müssen zwei Aspekte berücksichtigt werden. Zunächst wird beschrieben, wieso einige Suchmaschinen nicht mit Framesets umgehen können und wie
sich dieses Unvermögen auswirkt, wenn eine solche Suchmaschine auf eine mit Framesets generierte Seite trifft. Danach werden dann die Probleme geschildert, die auftreten
können, auch wenn Framesets von der Suchmaschine unterstützt werden.
AltaVista
Excite
HotBot/
Inktomi
Infoseek
Lycos
Northern Web
Verity
Light
Crawler
Frames
Ja
Nein
Nein
Nein
Teilweise
Ja
Ja
Ja
Clientsite
Imagemaps
Ja
Nein
Nein
Ja
Nein
Ja
Ja
Ja
Serversite
Imagemaps
Nein
Nein
Nein
Nein
Nein
Nein
Nein
Nein
JavaScript
Nein
Nein
Nein
Nein
Nein
Nein
Nein
Nein
Tabelle 2: Von Suchmaschinen nicht unterstützte HTML-Funktionen
Um die angesprochene Problematik besser darstellen zu können, werden im Vorfeld
zunächst einige Begriffe definiert, und es wird näher auf die Technologie von Framesets
eingegangen. Der Einfachheit halber werden im Kontext dieser Arbeit Framesets mit
drei Frames betrachtet, die wie folgt aufgebaut sind (vgl. Abb. 7 auf folgender Seite):
-
ein Hauptframe, der für die gesamte Website oder Homepage relevante Links enthält (z. B. Home, Hilfe, Suchen etc.),
-
ein Navigationsframe, der die Navigation im aktuellen Kontext erleichtern soll und
-
ein Inhalts-(engl. Content) Frame, der die eigentlich anzuzeigenden Informationen
enthält.
Problemanalyse
29
Abb. 7: Aufbau der untersuchten Framesets
Der HTML-Quelltext für dieses einfache Frameset ist in Abb. 8 zu sehen. Eine Suchmaschine, die den HTML-Tag <frameset> nicht versteht, bekommt lediglich den
Textteil im Body-Bereich angezeigt. Sie kann jedoch nicht die einzelnen Frames verfolgen, womit die gesamte Website bzw. Homepage nicht durchsuchbar ist.
<html>
<head>
<title> Ein einfaches Beispiel für Framesets </title>
</head>
<frameset cols="20%,*" border="3">
<frame src="Navigation.html" name="Nav">
<frameset rows="*,4*">
<frame src="Haupt.html" scrolling="no" name="Main">
<frame src="Inhalt.html" name="Content">
</frameset>
<body>
Sorry! You need a frames-browser to view this site.
</body>
</frameset>
</html>
Abb. 8: HTML-Quelltext zur Generierung eines einfachen Framesets
Problemanalyse
30
Ein Problem ganz anderer Natur ergibt sich bei Suchmaschinen, die Websites mit
Framesets durchsuchen und indizieren können. Als Link für die gefundenen Seiten wird
jeweils die URL für den entsprechenden Inhalts-Frame, nicht aber für das Frameset, in
der Trefferliste angezeigt. Verfolgt ein Benutzer diesen Link, bekommt er zwar den
Inhalt und somit die Information, die er sucht, dargestellt, die zugehörigen Navigationsframes fehlen jedoch, so daß ein weiteres Navigieren innerhalb der gefundenen Website
bzw. Homepage oft nicht möglich ist.
Image Maps sind ein weiteres Mittel, die Navigation zu vereinfachen. Auch in der aktuellen Version der Publishing-Komponente von NetFicient wird für die Hauptnavigation
eine Image Map benutzt (vgl. Abb. 9). Unter einer Image Map versteht man eine Grafik,
der ein Koordinatennetz mit Links hinterlegt ist. Je nachdem, in welchen Bereich der
Benutzer mit der Maus klickt, wird eine andere URL aufgerufen (vgl. Maurer 1996, S.
57ff.). Zudem unterscheidet man nach dem Ort der Ausführung serverside und clientside Image Maps. Da serverside Image Maps aufgrund ihrer technologischen Eigenschaften nicht für Suchmaschinen zugänglich sind, konzentrieren sich die folgenden
Darstellungen auf die clientside Image Maps.
Abb. 9: Hauptnavigation in NetFicient als Image Map
Wie in Tabelle 2 zu sehen, können drei der betrachteten Suchmaschinen nicht mit Image
Maps umgehen. Dies hat zur Folge, daß die in der Image Map hinterlegten Links nicht
vom Spider weiterverfolgt werden können, da er die HREF=“...“-Einträge im AREAAbschnitt nicht als Links identifiziert (vgl. Abb. 10 auf Seite 31). Besonders stark wirkt
sich dies im Zusammenhang mit den sehr beliebten Site Maps oder Navigation Maps
aus, bei denen der Einstieg zu einer Website bzw. die gesamte Navigation über Image
Maps realisiert wird. Derart gestaltete Seiten sind dann von den betroffenen Suchmaschinen nicht erfaßbar.
Problemanalyse
31
<IMG SRC="./header.gif" BORDER=0 WIDTH="778" HEIGHT="27"
USEMAP="#navbar" ISMAP>
<MAP NAME="navbar">
<AREA COORDS="460,0,495,27"
story.go(-1);">
<AREA COORDS="496,0,551,27"
story.go(1);">
<AREA COORDS="552,0,592,27"
<AREA COORDS="593,0,639,27"
<AREA COORDS="640,0,684,27"
<AREA COORDS="685,0,745,27"
<AREA COORDS="746,0,776,27"
HREF="javascript: parent.info.hiHREF="javascript: parent.info. hiHREF="/home.html" TARGET="_top">
HREF="/search.html" TARGET="info">
HREF="/phone.html" TARGET="info">
HREF="/feedback.html" TARGET="info">
HREF="/help.html" TARGET="info">
</MAP>
Abb. 10: HTML-Quelltext für eine Image Map
JavaScript ist eine eigene Programmiersprache und somit eigentlich kein direkter Bestandteil von HTML Da diese Sprache jedoch eigens zu dem Zweck geschaffen wurde,
HTML-Autoren ein Werkzeug in die Hand zu geben, mit dessen Hilfe sich Webseiten
optimieren lassen (vgl. Münz/Nefzger 1999), werden mit JavaScript verbundene Probleme ebenfalls in diesem Unterkapitel behandelt. JavaScript wird mittels des speziellen
HTML-Tags <Script> direkt in den HTML-Quelltext eingefügt, d. h. auch der JavaScript-Quelltext ist für die Suchmaschine komplett einsehbar. Trotzdem wird JavaScript, wie Tabelle 2 illustriert, von keiner der untersuchten Suchmaschinen unterstützt.
Dies kann zwei Ursachen haben. Die erste Möglichkeit wäre, daß der Spider die im JavaScript enthaltenen Links nicht erkennt, da sie nicht mit dem entsprechenden HTMLTag <A> ausgezeichnet sind (s. o.). Die andere und häufigere Ursache ist, daß der gesamte Bereich innerhalb des <Script>-Tags von der Suchmaschine ignoriert wird.
Daher sind Websites, deren Navigation allein auf JavaScript basiert, nicht von den Spidern durchsuchbar. Die restlichen Informationen sowie Links in der entsprechenden
Webseite werden jedoch korrekt vom Spider verarbeitet.
Anders verhält es sich mit CGI-Scripts. CGI-Scripts dienen meist zur Einbindung einer
externen Datenquelle (z. B. eine relationale Datenbank) in eine Webseite (z. B. das
Blättern in einem Warenkatalog). Da CGI-Scripts im Kontext mit Domino und speziell
NetFicient eine eher untergeordnete Rolle spielen, werden sie in den späteren Kapiteln
nicht weiter berücksichtigt, sollen aber der Vollständigkeit halber an dieser Stelle kurz
Problemanalyse
32
erwähnt und auf Probleme mit Suchmaschinen hin untersucht werden. Der Aufruf des
CGI-Scripts erfolgt meist über eine URL mit folgender Syntax, die von dem Spider und
verfolgt und an den Indexer weitergegeben werden kann (vgl. Hajji 1999, S. 571ff.):
http://hostname/pfad/scriptname?argumente. Auch die von dem CGI-Script
erzeugte Webseite besteht meistens aus Standard-HTML und kann von den Suchmaschinen einwandfrei verarbeitet werden. Probleme mit CGI-Scripts ergeben sich nur,
wenn zum Aufruf des Scripts Parameter notwendig sind, die zunächst vom Benutzer
eingegeben werden müssen (z. B. die Suche in einem Warenkatalog über Stichwörter).
3.1.3 Java
Mit Java ergeben sich für den Webdesigner eine Vielzahl von Möglichkeiten, seine
Website interaktiver und ansprechender zu gestalten. Dabei kann man sich neben dem
oben bereits dargestellten JavaScript auch Java-Applets und Java-Servlets bedienen.
Unter Java-Applets sind Java-Programme zu verstehen, die von einer Webseite über den
HTML-Tag <APPLET> aufgerufen werden und auf dem Client ausgeführt werden. Da
Java-Applets aber im Gegensatz zu JavaScript nicht im Quelltext, sondern als ausführbare Programme an den Webclient übergeben werden, können darin enthaltene Links
und Informationen nicht von den Suchmaschinen erfaßt werden. Dies spielt vor allem
im Zusammenhang mit Domino R5 eine große Rolle, da hier die Möglichkeit besteht,
interaktive Elemente wie Ansichten oder Navigatoren als Java-Applet zu realisieren
(siehe dazu auch Abschnitt 3.2.2). Die gleiche Problematik stellt sich mit Java-Servlets.
Der einzige Unterschied besteht darin, daß Java-Servlets, wie der Name schon sagt,
nicht auf dem Client, sondern auf dem Server selber ausgeführt und somit gar nicht erst
an den Client bzw. die Suchmaschine geschickt werden.
3.2 Lotus Notes/Domino Release 5
Seit der Version 4.5 hat sich Lotus Notes mit der Einführung der Domino Web Engine
in Verbindung mit einem HTTP-Servertask (vgl. Abschnitt 2.3) den Web- und Intranettechnologien weiter geöffnet. Auch wenn man als Webbenutzer beim Zugriff auf
einen Domino-Server den Unterschied zu einem gewöhnlichen Webserver wie z. B.
Apache kaum merkt, so äußern sich die durchaus vorhandenen Unterschiede doch im
Detail. Wie sich dies auf die Unterstützung von Suchmaschinen auswirkt, wird in den
folgenden beiden Abschnitten näher analysiert. Während sich der erste Abschnitt mit
Problemanalyse
33
den Eigenschaften des Domino-Servers als HTTP-Server beschäftigt (siehe auch Abschnitt 3.1.1), wird im anschließenden Abschnitt näher untersucht, wie die einzelnen
Notes-Elemente beim Webzugriff dargestellt werden. Im Blickpunkt steht dabei jedoch
lediglich, wo es zu Problemen mit Suchmaschinen kommen kann. Einen detaillierten
Vergleich von Notes/Domino-Technologien und Webtechnologien kann der interessierte Leser in Smolnik (1999) nachlesen. Schließlich werden noch spezifische Einträge
in der Serverkonfiguration von Domino betrachtet, die im Zusammenhang mit Suchmaschinen wichtig sein können.
3.2.1 Lotus Domino als Webserver
Um über das Web auf Notes-Datenbanken, Ansichten, Dokumente usw. zugreifen zu
können, ist eine spezielle URL-Syntax entwickelt worden, die wie folgt definiert ist:
http://hostname/datenbank/DominoObjekt?Aktion&Argumente
Wobei15
-
Hostname für den Namen des TCP/IP-Hosts steht (in diesem Fall der Domino-Ser-
ver).
-
Datenbank für den Namen der Datenbank steht, inklusive der Dateierweiterung
„.nsf“ sowie evtl. dem relativen Pfad zu dem Verzeichnis, in dem die Datenbank
liegt.
-
DominoObjekt das aufzurufende Notes/Domino-Element bezeichnet wie z. B. eine
Ansicht, eine Maske oder ein Dokument. Dabei kann das Element sowohl durch
seinen Namen oder Alias als auch durch die von Domino vergebene Notes- oder
Universal-Id angesprochen werden.
-
Aktion die anzuwendende Operation spezifiziert. Hierzu zählen beispielsweise
?OpenPage, ?OpenView, ?OpenDocument etc.
-
Argumente als optionale Parameter für die Aktion mit übergeben werden können.
Diese spezielle Syntax kann im Kontext von Suchmaschinen zu Problemen führen. Laut
Sullivan (1999b) haben einige Suchmaschinen Probleme mit URLs, die Sonderzeichen,
15
Im folgenden wird lediglich eine zusammenfassende Beschreibung der Syntax gegeben. Eine ausführli-
che Aufstellung findet man in Mann (1999), S. 739ff.
Problemanalyse
34
besonders das Fragezeichen „?“ enthalten : „Also, avoid symbols in your URLs, especially the ? symbol. Search engines tend to choke on it.“ Dies kann sich darin auswirken, daß derartige URLs entweder ganz ignoriert werden oder aber die URL ab dem
„?“-Zeichen abgeschnitten wird, so daß der Link danach nicht mehr so funktioniert, wie
ursprünglich intendiert. Dieses Phänomen war jedoch nur mit einigen Suchwerkzeugen
(siehe Abschnitt 2.5) zu beobachten, nicht jedoch mit den hier betrachteten Suchmaschinen, so daß dieses Problem hier nicht weiter verfolgt wird. Ein weiteres Problem
entsteht durch die Adressierung der Notes-Elemente in der URL. Da durch die unterschiedlichen Bezeichnungsmöglichkeiten (Name, Alias oder Universal-ID) auch verschiedene URLs entstehen, werden die Seiten von den Suchmaschinen mehrfach indiziert. Bedenkt man hierbei, daß in einer URL mehrere Notes-Elemente auftreten können
(z. B. Datenbank, Ansicht, Dokument), kann es passieren, daß eine Seite theoretisch bis
zu neunmal von der Suchmaschine als neu erkannt wird.
In Abschnitt 3.1.1 wurde bereits die Problematik bei fehlerhaft oder gar nicht gesetzten
Werten für die HTTP-Header Last-Modified und Expires angesprochen. Im folgenden wird nun explizit untersucht, welche Daten der Domino-Server im HTTPHeader zurückgibt. Dabei müssen, wie in Tabelle 3 auf Seite 35 zu sehen ist, die einzelnen Designelemente von Domino differenziert betrachtet werden. Zudem werden zwei
verschiedene Ausprägungen der Felder im HTTP-Header betrachtet. Zum einen wird
mit Hilfe eines Netzwerk-Utilities der Header direkt vom Domino-Server abgerufen,
zum anderen werden mittels eines Webbrowsers16 die entsprechenden Werte abgefragt.
Die Ergebnisse der Untersuchung sind der genannten Tabelle 3 zu entnehmen. An dieser Stelle sei nur beispielhaft ein HTTP-Header aufgeführt (siehe Abb. 11), eine komplette Auflistung aller HTTP-Header dieses Testes ist in Anhang 9.2 zu finden.
HTTP/1.1 200 OK
Server: Lotus-Domino/Release
Date: Thu, 07 Oct 1999 12:04:16 GMT
Connection: close
Content-Type: text/html; charset=US-ASCII
Content-Length: 462
Last-Modified: Thu, 07 Oct 1999 11:50:38 GMT
Expires: Thu, 07 Oct 1999 11:50:38 GMT
16
In diesem Fall der Netscape Navigator in der Version 4.5
Problemanalyse
35
Abb. 11: HTTP-Header für eine Page mit Pass Thru HTML
Wie im anschließenden Abschnitt beschrieben wird, muß bei Domino R5 zusätzlich
unterschieden werden, ob die Elemente als Java-Applet oder als HTML-Quelltext übersetzt werden. Zudem können die Inhalte auch direkt als HTML behandelt werden (Pass
Thru HTML). Dies hat auch Auswirkungen auf den HTTP-Header. So gibt der DominoServer nur Daten für Last-Modified und Expires zurück, wenn die Seiten- bzw.
Dokumenteninhalte als HTML interpretiert werden. Werden Notes-Elemente angefordert, die zunächst übersetzt werden müssen, gibt der Domino-Server diese HeaderInformationen gar nicht zurück. Einzige Ausnahme stellen Dokumente dar, die Felder
mit programmiertem HTML-Text (dynamisches HTML) beinhalten. Hier gibt der Domino-Server beide Daten zurück, jedoch werden sie auf das aktuelle Datum und die
aktuelle Zeit gesetzt. Dieses Vorgehen ist von Seiten des Domino-Servers auch logisch
begründbar, da die jeweilige Seite jedesmal neu erstellt bzw. berechnet wird. Ansichten
werden an dieser Stelle nicht differenziert betrachtet, da bei allen Varianten keine Header-Informationen zurückgegeben werden. Auf der Clientseite wird dementsprechend
das gegebene Datum ausgegeben bzw. „unknown“ oder „no date given“ angezeigt.
Designelemente
HTTP-Header
Navigator Informationen
Web-Darstellung
Last-Modified
Expires
Last-Modified
Expires
Pass Thru HTML
Ja
Ja
Datum
Datum
Nein
Nein
Unknown
No date given
Ja
Ja
Datum
Datum
Notes
Nein
Nein
Unknown
No date given
Dynamisches HTML
Now
Now
Datum
Datum
Ansichten
Nein
Nein
Unknown
No date given
Gliederungen
Nein
Nein
Unknown
No date given
Rahmengruppen
Nein
Nein
Unknown
No date given
Seiten
Notes
Dokumente
Pass Thru HTML
Tabelle 3: Zusammenhänge zwischen Notes-Elementen und HTTP-Header
Problemanalyse
36
Damit entsteht also genau die in Abschnitt 3.1.1 beschriebene Problematik. Aber auch
wenn die untersuchten HTTP-Header zurückgegeben werden, benutzt der DominoServer für das Expires-Datum immer das gleiche Datum, welches im LastModified Header steht. Dadurch kann es theoretisch zu Problemen kommen, da der
Indexer die entsprechenden Seiten als nicht mehr gültig klassifiziert und somit nicht in
die Datenbank aufnimmt. Da aber alle hier betrachteten Suchmaschinen auch von Domino-Servern bereitgestellte Seiten in ihren Indizes haben, ist davon auszugehen, daß
dieser Header von den Suchmaschinen ignoriert wird. Diese Tatsache wurde auch von
den Mitarbeitern in der Abteilung Search Engine Technology der Deutschen Bank AG
bestätigt.
3.2.2 Design Elemente von Lotus Notes
Während der Fokus im vorangegangenen Abschnitt auf dem HTTP-Protokoll lag, wird
nun ein Blick auf das von Domino erzeugte HTML geworfen. In Abschnitt 3.1.1 wurde
bereits die Aufgabentrennung von Domino Web Engine und HTTP-Servertask beschrieben. Solange keine spezifischen Notes-Elemente involviert sind, verhält sich der
Domino-Server daher wie ein normaler Webserver und gibt die angeforderten Webseiten zurück (z. B. HTML-Dateien im entsprechenden Serververzeichnis). Wird mit der
aufgerufenen URL aber ein Notes-Element angefordert, wird dieses zunächst von der
Domino Web Engine für die Webdarstellung konvertiert. Auf die Art und Weise dieser
Konvertierung kann der Entwickler, wie weiter oben bereits kurz angedeutet wurde,
Einfluß nehmen.
Zunächst kann für jede Datenbank angegeben werden, ob zur Erzeugung der Seiten bei
einem Webzugriff JavaScript verwendet werden soll (siehe Abb. 12 auf Seite 37). Damit wird die Übersetzung von @Command-Funktionen (z. B. in Aktionsleisten) in JavaScript ermöglicht. Da derartige Kommandos für Suchmaschinen keine Relevanz haben
und JavaScript von den Suchmaschinen ignoriert wird, spielt diese Einstellung in den
späteren Darstellungen keine Rolle. Für die diversen Notes-Elemente stehen neben der
standardmäßigen HTML-Konvertierung zwei weitere Methoden zur Verfügung: Mit
Pass Thru HTML wird Domino angewiesen, den Inhalt als nativen HTML-Quelltext zu
interpretieren und direkt an den Client zurückzusenden (siehe Abb. 12). Zudem können
bei interaktiven Elementen wie z. B. Ansichten auch sogenannte Domino-Applets (vgl.
Axt/Hertel/Wagner (1999), S. 556ff.) benutzt werden. Damit sind vordefinierte Java-
Problemanalyse
37
Applets gemeint, die von Domino seit R5 als Bausteine angeboten werden (siehe Abb.
13 auf Seite 38). Im folgenden werden daher die einzelnen Notes-Elemente nach ihrer
Darstellungsweise differenziert auf Probleme hin analysiert, die im Zusammenhang mit
Suchmaschinen entstehen können.
Abb. 12: JavaScript und Pass Thru HTML
Die Option, den Inhalt als Pass Thru HTML zu interpretieren, steht nur für die NotesElemente Seite, Dokument/Maske und Ansicht zur Verfügung. Bei Seiten und Dokumenten wird dementsprechend der HTML-Quelltext direkt eingegeben bzw. durch Formeln „berechnet.“ Solange dabei keine problematischen HTML-Funktionen (vgl. Abschnitt 3.1.2) benutzt werden, stellen diese Elemente kein Problem für Suchmaschinen
dar. Um Pass Thru HTML für Ansichten verwenden zu können, muß der entsprechende
HTML-Quelltext (im Zusammenhang mit Ansichten meistens Links) für die entsprechenden Spalten programmiert werden. Da bei dieser Vorgehensweise weder Kategorien noch die automatisch generierten Ansichtslinks (siehe S. 38) angezeigt werden, ergeben sich auch keine Probleme bei der Erfassung der Links durch den Spider.
Identifiziert der Domino-Server ein Element nicht als Pass Thru HTML, generiert die
Domino Web Engine den entsprechenden HTML-Quelltext, um das angeforderte NotesElement im Web darzustellen. Seiten und Dokumente stellen dabei den einfachsten Fall
dar. Der Inhalt wie Text, RichText, Bilder oder Tabellen werden durch ihre HTMLPendants dargestellt und verursachen somit keine Probleme. Rahmengruppen werden
für das Web als HTML-Framesets dargestellt und sind daher mit den bereits erläuterten
Problemen für Suchmaschinen behaftet. Komplizierter gestalten sich dynamische
Problemanalyse
38
Notes-Elemente wie Gliederungen und Ansichten. Beide werden beim Zugriff über das
Web zu HTML-Tabellen konvertiert, was für Suchmaschinen keine Probleme bereitet.
Anders verhält es sich, wenn die Ansichten bzw. Gliederungen Kategorien enthalten.
Das Expandieren und Kollabieren der einzelnen Kategorien geschieht dabei über spezielle URL-Kommandos (vgl. Abschnitt 3.2.1), wodurch für jede mögliche Konstellation
eine eigene URL entsteht, die von dem Spider als neu klassifiziert wird. Bestehen die
einzelnen Kategorien auch noch aus Unterkategorien, steigert sich die Anzahl der möglichen URLs exponentiell, wodurch sowohl der Server als auch die Suchmaschine
übermäßig belastet werden.
.
Abb. 13: Verwenung von Domino-Applets zur Darstellung beim Webzugriff
Ansichten bringen bei der HTML-Darstellung noch ein weiteres Problem mit sich. Wie
in Abb. 14 auf Seite 39 illustriert, generiert die Domino Web Engine einige für Ansichten spezifische Links, die aus dem Notes-Client bekannt sind und der Navigation innerhalb der Ansichten dienen. Im folgenden werden die einzelnen Links näher beschrieben
und ihr Problem im Zusammenhang mit Suchmaschinen dargestellt.
-
Search öffnet eine von Domino generierte Suchmaske, mit der man die aktuelle Ansicht durchsuchen kann. Diese Seite sollte jedoch Suchmaschinen nicht zugänglich
sein, da diese Seite nicht indiziert werden muß.
-
Next/Previous dient eigentlich zur Navigation innerhalb der Ansicht, falls die Ansicht mehr Dokumente enthält, als angezeigt werden (vgl. Abschnitt 3.2.1). Problematisch für Suchmaschinen ist allerdings, daß diese Links auch zur Verfügung ste-
Problemanalyse
39
hen, wenn der Anfang bzw. das Ende der Ansicht erreicht wird, so daß eine Endlosschleife entsteht, wenn der Spider nicht erkennt, daß er die Seite schon besucht hat.
-
Expand/Collapse werden nur bei Ansichten mit Kategorien benötigt. Mit Expand
werden alle Kategorien geöffnet, mit Collapse alle Kategorien geschlossen. Auch
wenn eine Ansicht keine Kategorien enthält, wird die gleiche Ansicht mehrmals von
der Suchmaschine indiziert, da durch das Anhängen der Argumente ExpandView
bzw. CollapseView eine neue URL entsteht (siehe auch Abschnitt 3.1.1). Diese
beiden zusätzlichen URLs entstehen für jede mit Previous/Next anwählbare Seite,
wodurch bei einer großen Anzahl von Dokumenten die Suchmaschine und auch der
Domino-Server unnötig belastet werden.
Abb. 14: Domino-Ansicht als HTML-Tabelle mit Navigation
Für die Notes-Elemente Ansicht und Gliederung bietet Domino mit R5 spezielle Applets zur Darstellung im Web (siehe Abb. 13). Damit soll das Look&Feel und die Funktionalität des Notes-Clients in akzeptabler Form auch für das Web verfügbar gemacht
werden. Auch wird durch die Ausführung der Applets auf dem Client der Server weni-
Problemanalyse
40
ger belastet und ein Geschwindigkeitsvorteil17 erzielt. Wie in Abschnitt 3.1.3 beschrieben, können die Spider der Suchmaschinen diese Applets jedoch nicht verarbeiten und
somit nicht über die Links auf den Inhalt der Website zugreifen. Anders verhält es sich
mit dem RichText-Applet. Zur Anzeige von RichText-Objekten im Web benutzt die
Domino Web Engine Standard-HTML. Für die Eingabe von RichText über das Web
stellt Domino ein spezielles RichText-Applet zur Verfügung, um zumindest grundlegende Formatierungsoptionen bereitzustellen. Da das Erstellen bzw. Bearbeiten von
Dokumenten im Zusammenhang mit Suchmaschinen nicht von Interesse ist, wird dieser
Punkt im weiteren Verlauf nicht weiter berücksichtigt.
Schließlich seien im Zusammenhang mit Notes-Elementen noch eingebettete Objekte
genannt. Damit sind Notes-Elemente gemeint, die in eine Seite oder Maske integriert
werden. Dadurch entstehen für die Seite bzw. Maske die gleichen Probleme, die das
eingebettete Notes-Element mitbringt (z. B. ein Ansicht-Applet).
Darstellung
Probleme im Zusammenhang mit Suchmaschinen
Pass Thru HTML
Keine, außer der HTML-Quelltext enthält Framesets oder
Image Maps.
Generiertes HTML
-
Rahmengruppen (siehe Framesets, Abschnitt 3.1.2)
-
Kategorisierte Ansichten und Outlines / Sektionen in Dokumenten
-
Navigationslinks von Ansichten
Domino-Applets
Applets sind generell nicht für den Spider zugänglich.
Eingebettete Objekte
Übertragen ihre Probleme auf das jeweilige Notes-Element.
Tabelle 4: Probleme in Abhängigkeit von der Webdarstellung der Notes-Elemente
3.2.3 Konfiguration des Domino-Servers
In diesem Abschnitt werden Einträge in der Serverkonfiguration untersucht, die zu Problemen im Zusammenhang mit Suchmaschinen führen können. Im Fokus der Betrachtungen stehen dabei die Einstellungen für die Domino Web Engine, speziell der Ab-
17
Man darf dabei allerdings die längere Ladezeit des Applets nicht vergessen.
Problemanalyse
41
schnitt für Conversion/Display (siehe Abb. 15 am Ende dieses Abschnitts), in der einige
generelle Parameter für den Webzugriff gesetzt werden können.
Insbesondere folgende Einträge sind vor dem Hintergrund dieser Arbeit interessant:
-
Default/Maximum lines per view page gibt an, wie viele Zeilen beim Webzugriff auf
eine Ansicht standardmäßig bzw. maximal angezeigt werden. Dadurch werden bei
größerer Anzahl an Dokumenten die bereits erwähnten Navigationslinks mit den
diskutierten Nachteilen für Suchmaschinen angezeigt. Da diese bei Ansichten mit
HTML-Inhalt von Domino nicht generiert werden, können Suchmaschinen auf nicht
angezeigte Links bzw. Informationen nicht zugreifen.
-
Make this site accessible to web search site crawlers. Dieser undokumentierte Servereintrag hat momentan noch keine sichtbare Funktionalität. Der Administrator
sollte diesen Eintrag trotzdem auf „enabled“ setzen, da in kommenden Versionen
von Domino dieser Eintrag unterstützt werden könnte.
Problemanalyse
42
Abb. 15: Serverkonfiguration für die Domino Web Engine
3.3 Suchmaschinensoftware
In den vorangegangenen Abschnitten wurde dargelegt, wie sich die beiden Technologieströmungen Internet und Domino auf die Arbeitsweise von Suchmaschinen, konkret
den Spider und den Indexer, auswirken. Dabei wurden vorrangig Probleme behandelt,
die das Erfassen der Webseiten und deren Inhalte betrafen. Hier stehen nun die Probleme im Vordergrund, deren Ursache direkt bei den Suchmaschinen, speziell der Softwarekomponente, zu suchen ist.
Die Suchmaschinensoftware besteht gemäß der Darstellung in Abschnitt 2.2.3 aus zwei
Komponenten, einem Interface zur Eingabe von Suchanfragen und einem Generator, der
durch Sortierung der Suchergebnisse die Trefferliste erzeugt und anzeigt. Diese Trefferliste ist jedoch in den meisten Fällen zu groß und enthält auch viele Seiten, die mit
dem intendierten Suchergebnis nicht korrelieren. Das Beispiel in Abb. 16 zeigt, daß
Altavista selbst bei der Suche nach dem eher seltenen und sehr fachspezifischen Wort
„Bonitätsprüfung“ am 09.10.1999 fast 1.000 relevante Seiten findet. Diese Zahl wächst
bei anderen Sucheingaben noch erheblich an, wie eine Suche nach dem Begriff „kredit“
mit über 70.000 Treffern verdeutlicht.
Problemanalyse
43
Abb. 16: Suchergebnis für Bonitätsprüfung bei Altavista
Diese großen Trefferlisten sind das Resultat einiger grundlegender Eigenschaften von
Suchmaschinen. Auch wenn sie nur einen vergleichsweise kleinen Teil des WWW indizieren, geht die Zahl der indizierten Seiten trotzdem in den zwei- bis dreistelligen Millionenbereich. Diese große Anzahl indizierter Seiten ist einer der wesentlichen Vorteile
von Suchmaschinen gegenüber Webkatalogen, bringt aber gleichzeitig einen großen
Nachteil mit sich. Durch die automatische Indizierung der gefundenen Webseiten ist die
Zuordnung zu relevanten Themengebieten nicht so gut wie bei von Hand erstellten Katalogen. Zudem kann der Indexer keine Täuschungsversuche der Anbieter erkennen. Mit
Täuschungsversuchen sind hierbei falsche Einträge in den Meta-Tags gemeint, mit denen mehr Besucher auf die eigene Website gelockt werden sollen. Eine andere Ursache
für zu große oder falsche Trefferlisten sind nicht genügend exakt formulierte Suchanfragen. Die betrachteten Suchmaschinen bieten zwar alle Parameter und Funktionen, um
die Suche zu präzisieren, für den Gelegenheitsnutzer sind die Formulierungen aber zu
kompliziert. Ein weiteres Problem stellt die Schreibweise der Suchanfragen dar. Benutzt
man beispielsweise als Schlagwort „Bonitaetsprüfung“ anstelle von „Bonitätsprüfung“,
findet Altavista nur noch eine relevant Seite
Ein bisher nicht betrachteter Aspekt bezüglich der generierten Ergebnislisten ist die
Qualität der gefundenen Informationen. Auch wenn die gefundene Webseite Informationen zu dem gesuchten Thema anbietet, gibt es keine Möglichkeit für den Benutzer,
den Wert bzw. die Richtigkeit der Informationen abzuschätzen.
3.4 Kernanforderungen an NetFicient R2
Im Gegensatz zu den vorigen Analysen, die sich auf eher technische Merkmale konzentrieren, werden in diesem Abschnitt einige konzeptionelle Bedingungen dargestellt, die
im Zusammenhang mit Suchmaschinen zu beachten sind. Von den im Abschnitt 2.5
vorgestellten Kernanforderungen an die neue Version von NetFicient sind diesbezüglich
die Punkte Mehrsprachigkeit, Multikontext und Multiframefähigkeit relevant.
Die Multiframefähigkeit oder Frame-in-Frame-Technologie stellt eine Erweiterung der
in Abschnitt 3.1.2 beschriebenen Frame-Problematik dar, da zu einer Inhaltsseite nun
mehrere Navigationsframes gehören können. Mehrsprachigkeit und Multikontext bedeuten für die Suchmaschinen, daß eine Webseite von NetFicient mehrfach indiziert
werden muß, also in verschiedenen Sprachen oder in unterschiedlichen Themenkontex-
Problemanalyse
44
ten. Hier gilt es im nächsten Kapitel Wege zu finden, dies über verschiedene URLs zu
gewährleisten, da Suchmaschinen den Unterschied nur erkennen, wenn sie eine neue
URL vorfinden.
Evaluierung von Lösungsansätzen
45
4 Evaluierung von Lösungsansätzen
Für viele der im letzten Kapitel genannten Probleme haben sich im Laufe der Zeit Standardlösungen etabliert, die vor allem auf allgemeine Problematiken wie z. B. Framesets
zielen. Vor dem bereits beschriebenen Hintergrund NetFicient und Domino als eingesetztem Webserver reichen diese Standardlösungen aber meist nicht aus. Daher werden
im Verlauf dieses Kapitels, wenn vorhanden, zunächst Standardlösungen präsentiert und
ihre Eignung und Relevanz für NetFicient dargestellt. Daraufhin werden diese erweitert,
bzw. es werden neue Lösungsansätze entwickelt und ihre jeweiligen Vor- und Nachteile
diskutiert. Diese Evaluierung der einzelnen Lösungen dient dann als Grundlage für das
nächste Kapitel, in dem ein umfassendes Konzept für die Integration von Suchmaschinen entwickelt wird.
Während in der vorangegangenen Problemanalyse die Sichtweise auf den verursachenden Bereichen lag, werden die Probleme in diesem Kapitel nach ihrer Auswirkung auf
Suchmaschinen geordnet, um dann Lösungsansätze für die jeweiligen Bereiche zu entwickeln. Daher werden zunächst Ansätze für die Probleme präsentiert, die mit der korrekten Erfassung der Webseiten durch den Spider und den Indexer zusammenhängen.
Der anschließende Abschnitt konzentriert sich auf Lösungen bezüglich der Suchmaschinensoftware, speziell auf die Ranking-Verfahren und das Benutzerinterface. Der
letzte Abschnitt dieses Kapitels beschäftigt sich schließlich noch mit dem Aspekt der
Sicherheit im Zusammenhang mit Suchmaschinen.
4.1 Korrekte Erfassung der Webseiten durch Spider und Indexer
Um eine einwandfreie Erfassung der Webseiten zu gewährleisten, müssen mehrere
Punkte berücksichtigt werden. Für den Spider müssen die Seiten erreichbar sein, und
auch die Verknüpfungen innerhalb der gesamten Website müssen von ihm verfolgbar
sein. Zudem ist es nötig, daß die Inhalte der Webseiten für den Indexer keine Probleme
darstellen. Dazu werden im folgenden für die bereits dargestellten Probleme bezüglich
der HTTP-Header, den beiden HTML-Funktionen Framesets und Image Maps, den dynamischen Konzepten JavaScript und Java-Applets sowie den einzelnen NotesElementen Lösungsvorschläge vorgestellt bzw. entwickelt, und es wird explizit auf ihre
Vor- und Nachteile eingegangen.
46
4.1.1 Manipulation der HTTP-Header unter Lotus Domino
Wie in der Problemanalyse (siehe Abschnitt 3.1.1) ausführlich dargestellt wurde, geht
es hierbei um die beiden HTTP-Header Last-Modified und Expires. Um diese beiden Datumswerte fehlerfrei an die Suchmaschine zu übergeben, können zwei grundverschiedene Ansätze zum Einsatz kommen. Entweder benutzt man nur Notes-Elemente,
für die der HTTP-Servertask die richtigen Werte zurückgibt, oder man modifiziert diese
Werte bei jedem Aufruf durch geeignete Domino- und Web-Programmiermittel.
Zur Modifikation der HTTP-Header stehen unter Domino mehrere Mittel zur Verfügung. Der Einsatz eines Servlets stellt die erste der hier betrachteten Möglichkeiten dar.
Mit einem Servlet ist es möglich, den HTTP-Header komplett selber zu schreiben und
somit die richtigen Werte für Last-Modified und Expires an den Spider zu übergeben. Servlets werden in Domino ausschließlich in Java implementiert, der Zugriff auf
die Domino-Elemente geschieht dabei über die Common Object Request Broker Architecture (CORBA) Schnittstelle (vgl. Axt/Hertel/Wagner 1999, S. 327-333). Die Vorgehensweise des Servlets sieht dabei wie folgt aus. Das Servlet liest zunächst von dem
angeforderten Objekt das Last-Modified und das Expires Datum über die
CORBA-Schnittstelle aus. Anschließend muß die Content-Length des Objektes berechnet werden, bevor der HTTP-Header mit Hilfe der Java-Anweisung response.setHeader(“Last-Modified: ...“) geschrieben werden kann. Der Vorteil
dieser Methode liegt in der Performance. Das Servlet wird nur einmal in den Speicher
des Servers geladen und dann bei jedem Aufruf ausgeführt. Zudem ist es möglich, über
spezielle Eigenschaften des Servers das Servlet bereits beim Starten des HTTP-Server
Tasks zu laden (vgl. Lotus Development Corporation 1999), so daß auch beim ersten
Aufruf keine Zeitverzögerung entsteht. Problematisch dagegen ist die Aktivierung des
Servlets. Bei Domino werden Servlets über die URL gestartet, wobei folgende Optionen
zur Verfügung stehen:
-
Servlet URL path: Mit dem Pfad in der URL wird Domino signalisiert, daß es sich
um ein Servlet handelt.
-
Class path: Liste von Pfaden, in der Domino nach Servlets und Klassen sucht.
-
Servlet file extension: Liste von Dateierweiterungen, welche Domino den Aufruf
eines Servlets signalisieren. Dabei wird jeder Dateierweiterung genau ein Servlet
zugewiesen.
47
Anstelle des eigentlichen Objektes muß also zunächst das Servlet aufgerufen werden,
wobei die URL des angeforderten Objektes dem Servlet als Parameter übergeben wird.
Hier bieten sich zwei Implementierungsmöglichkeiten. Zum einen kann man das Servlet
standardmäßig bei jeder HTTP-Anforderung starten. Nachteil dieser Methode ist jedoch
eine hohe Serverbelastung. Eine bessere Lösung wäre hier die Benutzung einer speziellen „Suchseite“, die nur für Suchmaschinen erreichbar ist und Links auf alle Webseiten
innerhalb der Website enthält (vgl. Abschnitt 4.1.5). Auf diese Weise erreicht man, daß
das Servlet nur bei Zugriffen von Suchmaschinen aufgerufen wird, nicht aber bei Anfragen von anderen Web-Clients.
Eine weitere Möglichkeit, den HTTP-Header zu modifizieren, bieten Agenten, die über
die Web-Query-Open Eigenschaften von Domino-Masken automatisch ausgeführt werden, wenn ein Dokument über das Web aufgerufen wird, das auf einer derartigen Maske
basiert. Für die Implementation kann der Entwickler hierbei zwischen einem JavaAgenten und einem LotusScript-Agenten wählen. Eine undokumentierte Funktion von
Domino ermöglicht es, über einfache Ausgabeanweisungen den HTTP-Header von
Hand zu schreiben. Die Verwendung von Agenten hat jedoch einen entscheidenden
Nachteil. Da Agenten sehr viel Belastung für den Server bedeuten, gelangt selbst ein
hochperfomanter Server bei vielen gleichzeitig laufenden Agenten schnell an seine
Grenzen. Zwar läßt sich die Belastung analog zu der im Zusammenhang mit Servlets
bereits vorgestellten Suchseite begrenzen, selbst dann kann es aber je nach Konfiguration der Suchmaschine zu „Time-Out“-Fehlermeldungen aufgrund zu langer Antwortzeiten kommen.
Die dritte Alternative ist die Benutzung des HTML Meta-Tag HTTP-EQUIV, mit dem
auch Felder im HTTP-Header modifiziert werden können. Dazu werden die jeweiligen
Werte wie folgt in die HTML-Header-Eigenschaft der entsprechenden Maske eingetragen: <Meta NAME = “HTTP-EQUIV“ CONTENT =“Last-Modified:...“>. Diese
Methode stellt zwar die einfachste Lösungsalternative dar, erreicht aber nicht vollständig die angestrebte Funktionalität. Tests haben ergeben, daß der Server bei Anforderung
des HTTP-Header vom Spider nicht auf den HTML-Inhalt zurückgreift, wodurch die
Modifikation auf dieser Ebene wirkungslos ist. Lediglich wenn die Webseite selber angefordert wird, werden diese Meta-Tags interpretiert. Daher bekommt bei dieser Lösung
der Indexer zwar die richtigen Datumswerte, die ursprüngliche Problematik der erhöhten Netzbelastung bleibt jedoch bestehen.
48
Der Vollständigkeit halber sei an dieser Stelle noch ein weiterer Lösungsansatz präsentiert, der darin besteht, mittels Java einen eigenen HTTP-Server unter Domino zu implementieren. Diese Vorgehensweise ist jedoch für NetFicient nicht relevant, da man
hier im Prinzip die Funktionsweise der Domino Web Engine nachprogrammiert und
somit auch auf den Domino-Server ganz verzichten könnte.
Die letzte der hier präsentierten Alternativen verfolgt einen anderen Ansatz als die bisher dargestellten Lösungen. Wurde dort versucht, den HTTP-Header zu modifizieren,
hat dieser Ansatz zum Ziel, daß der Domino-Server von sich aus die richtigen Informationen zurückgibt, indem nur die entsprechenden Design-Elemente benutzt werden. Da
man sich hierbei aber auf Seiten und Masken mit Pass Thru HTML beschränken muß
(vgl. Abschnitt 3.2.2), würde damit die Funktionalität aber stark eingeschränkt werden.
Aufgrund der beschriebenen Probleme kommen die beiden zuletzt dargelegten Lösungsvorschläge nicht in Betracht. Der Einsatz von Servlets bzw. Agenten stellt trotz
der damit verbundenen hohen Systembelastung sicherlich die beste Möglichkeit dar,
wobei die leichtere Umsetzung durch Agenten gegen die geringere Systembelastung der
Servlets abgewogen werden muß. Steht die Performance im Vordergrund, ist die Verwendung des HTML-Tags HTTP-EQUIV die einzige Lösung. Auch wenn dieser Tag
keine Auswirkungen auf den Spider hat, garantiert er doch die spätere korrekte Aufnahme der Werte in den Index der Suchmaschine
4.1.2 Lösungsansätze für nicht unterstützte HTML-Funktionen
In diesem Abschnitt werden Lösungskonzepte für die teilweise nicht unterstützten
HTML-Funktionen Framesets und Image Maps dargestellt bzw. entwickelt. Wie bereits
in Abschnitt 3.1.2 beschrieben, müssen bezüglich Framesets zwei Problematiken berücksichtigt werden. Daher wird hier zunächst auf Lösungen eingegangen, die sich mit
der Unterstützung von Suchmaschinen beschäftigen, die nicht mit Framesets umgehen
können, bevor Lösungen für die dargestellte Bookmark-Problematik untersucht werden.
Suchmaschinen und Browser, die den Frameset-Tag nicht unterstützen, können nicht
auf die Informationen und Links innerhalb der einzelnen Frames zugreifen. Daher wurde mit dem Frameset-Tag auch ein spezieller NoFrame-Tag eingeführt. Mit dessen
Hilfe ist es möglich, auch für nicht framefähige Browser Informationen anzuzeigen.
Diese beschränken sich jedoch meist auf Fehlermeldungen wie „Sie brauchen einen
framefähigen Browser, um diese Seite anzuzeigen.“ Im Kontext von Suchmaschinen
49
läßt sich der NoFrame-Bereich nutzen, um die gesamte Website der Suchmaschine zugänglich zu machen. Dazu fügt man einfach einen Link im NoFrame-Bereich ein, der
auf eine spezielle Seite verweist, die Verknüpfungen zu allen Inhalts-Frames enthält
(siehe auch Abschnitt 4.1.5). Das Problem bei dieser Vorgehensweise ist, daß der Navigationskontext nicht mehr vorhanden ist, wenn ein Benutzer über die Suchmaschine
auf die Seiten zugreift. Die gleiche Problematik stellt sich auch bei Suchmaschinen, die
Framesets unterstützen. Diese können, wie in Abschnitt 3.1.2 beschrieben, die einzelnen
Frames durchsuchen, als Ergebnis geben sie aber auch nur eine einzelne aus dem Kontext gerissene Seite zurück. Mit dieser Bookmark-Problematik beschäftigen sich die
folgenden Ausführungen.
Zur Lösung der angesprochenen Problematik sind mehrere Ansätze denkbar. Die einfachste Methode stellt ein zusätzlicher Link auf jeder Seite dar, mit dessen Hilfe der
Benutzer die Navigationsframes manuell wieder hinzuladen kann. Bei NetFicient muß
in diesem Zusammenhang noch die angestrebte Multikontext-Funktionalität berücksichtigt werden. Daher reicht für NetFicient ein Link nicht aus. Vielmehr muß für jeden
Navigationskontext ein eigener Link eingefügt werden, so daß der Benutzer wählen
kann, wo er weiter nach Informationen suchen will.
Ein weiterer Ansatz ist es, die Navigationsframes mit Hilfe von JavaScript automatisch
hinzuzuladen. Da Suchmaschinen JavaScript nicht beherrschen und somit ignorieren,
ergeben sich in diesem Zusammenhang auch keine neuen Probleme. Während dieses
Vorgehen standardmäßig sehr einfach zu implementieren ist, muß man sich für die Umsetzung in NetFicient weiterführende Gedanken machen. Damit eine Suchmaschine
dieselbe Seite in verschiedenen Kontexten mehrfach in ihren Index aufnimmt, muß für
jeden Kontext auch eine andere URL existieren. Dabei unterscheiden Suchmaschinen
nicht nur die eigentliche Webadresse (Host + Pfad + Datei), sondern auch die
übergebenen Argumente. Anhand dieser Argumente kann man das JavaScript dahingehend erweitern, daß abgängig von den übergebenen Argumenten die entsprechenden
Navigationsframes hinzugeladen werden. Auch können auf diese Weise weitere Merkmale wie z. B. kontextabhängige Meta-Informationen hinzugefügt werden (siehe auch
Abschnitt 3.4).
Das neue Notes-Element Rahmengruppe stellt eine weitere Möglichkeit zur Lösung der
beschriebenen Problematik dar. Damit ist es möglich, ein Notes-Element wie z. B. eine
Seite fest mit einer Rahmengruppe zu verknüpfen. Dadurch wird erreicht, daß bei jedem
50
Aufruf das Element in der zugeordneten Rahmengruppe angezeigt wird, womit die
Bookmark-Problematik gelöst wäre. Problematisch in diesem Zusammenhang ist jedoch, daß jedes Element nur einer Rahmengruppe fest zugeordnet werden kann und
somit die geforderten Funktionalitäten Multikontext und Multiframe nicht unterstützt
werden können. Ein weiterer Nachteil ist, daß diese Lösung nur mit Suchmaschinen
funktioniert, die Framesets unterstützen, da es nicht möglich ist, den Inhaltsframe alleine anzuzeigen. Setzt man für den Navigationsframe Ansichten oder Gliederungen ein,
die durch HTML an Stelle von Java-Applets dargestellt werden, kann dafür die Entwicklung einer eigenen Suchseite entfallen, da die gesamte Homepage von Suchmaschinen mit den oben genannten Einschränkungen durchsuchbar ist.
Fast die Hälfte der wichtigen Suchmaschinen unterstützen keine Image Maps (siehe
Abschnitt 3.1.2). Eine einfache Lösung dieses Problems wäre es, neben oder unter der
Image Map mit einem Link auf eine andere Seite zu verweisen, die alternativ die Links
aus der Image Map in normaler Form enthält. Dies würde auch die Webbenutzer unterstützen, die Browser älterer Generationen verwenden oder aufgrund der Übertragungsrate das Anzeigen von Grafiken und somit auch Image Maps ausgeschaltet haben.
Eine weitere Möglichkeit wären „versteckte“ Links (engl. hidden links), d. h. die Links
für die Suchmaschine sind für „normale“ Benutzer nicht zu sehen. Dies wäre z. B. durch
einen „leeren“ Link in der Form <A HREF=“URL“></A> zu realisieren oder indem man
die Schriftfarbe der Hintergrundfarbe anpaßt. Einige Suchmaschinen deuten diese Vorgehensweisen jedoch als Spamming und ignorieren derartige Links (vgl. Tabelle 5 auf
Seite 55).
4.1.3 Unterstützung von JavaScript und Java-Applets
Zur Generierung von Webseiten können seit der Release 5 von Lotus Domino spezielle
Domino-Applets und JavaScript eingesetzt werden (vor allem für interaktive Elemente
wie Ansichten, Aktionsleisten etc.). Dies beinhaltet auf der einen Seite gegenüber der
Vorgängerversion einen Gewinn an Performance, auf der anderen Seite können Suchmaschinen, wie in Abschnitt 3.1.3 geschildert, solche dynamisch generierten Seiten
nicht verarbeiten.
Ein weit verbreiteter Ansatz ist es, für Suchmaschinen und nicht javafähige Browser
spezielle Seiten anzubieten. Bei JavaScript kann man dies über den HTML-Tag
NoScript realisieren (vgl. Münz/Nefzger 1998), indem man in diesem Bereich eine
51
Verknüpfung auf die spezielle Suchmaschinenseite einfügt. Da für Java-Applets keine
derartige Methode existiert, müssen andere Verfahren entwickelt werden, um den Spider auf die Suchmaschinenseite umzulenken. Ein Ansatz, der diese Vorgehensweise
verfolgt, nutzt die Möglichkeit, einen Spider beim Zugriff auf eine Seite zu identifizieren (Spider Spotting). Anhand eines speziellen HTTP-Headers läßt sich der Name des
anfragenden Clients ermitteln (z. B. Mozilla für Netscape). Auch die großen Suchmaschinen lassen sich auf diesem Weg identifizieren, um somit automatisch eine speziell
für Suchmaschinen erstellte Seite zurückgeben zu können. Da die Suchmaschinen allerdings aus Kontrollgründen manchmal auch unter Browsernamen auftreten, reicht diese
Abfrage allein nicht aus. Die IP-Adresse des anfragenden Clients ist ein weiterer Hinweis auf eine Suchmaschine, da deren IP-Adressen bzw. Hostnamen bekannt sind.18
Auch die im vorigen Abschnitt eingeführten versteckten Links können dazu eingesetzt
werden, um Suchmaschinen auf eine spezielle Seite zu verweisen. Neben der dort beschriebenen Umsetzung eines versteckten Links sei hier noch eine weitere Methode
genannt. Diese besteht in einer „Hidden Image Map“, d. h. eine Image Map mit einer
Breite und Länge von Null, die auf die alternative Seite verweist. Diese Methode hat
den Vorteil, daß nur Suchmaschinen diese Seite auch finden können. Leider unterstützen, wie bereits oben erwähnt, nicht alle Suchmaschinen Image Maps, so daß dies keine
alleinige Lösung ist, sondern vielmehr eine mögliche Ergänzung für die weiter oben
beschriebenen Lösungsansätze darstellt.
4.1.4 Suchmaschinengerechte Webdarstellung der Notes-Elemente
Die meisten Probleme ergeben sich für Suchmaschinen, wenn die Notes-Elemente explizit als Java-Applet oder mittels JavaScript für den Webzugriff dargestellt werden
(vgl. die Abschnitte 3.1.3 und 3.2.2). Die einfachste Lösung wäre daher, diese Funktionen komplett zu deaktivieren und nur mit der HTML-Generierung der Domino Web
Engine zu arbeiten. Will man nicht auf die Vorteile wie Performancesteigerung und
bessere Bedienbarkeit, die der Einsatz von Java-Applets mit sich bringt, verzichten,
muß der Zugriff für die Suchmaschine, wie im vorangegangenen Abschnitt erläutert,
über eine spezielle Suchseite erfolgen. Lediglich für die Darstellung von RichTextFeldern als Java-Applet kann auf diese Vorgehensweise verzichtet werden, da dieses
18
Siehe Anhang 9.1.2
52
nur zum Editieren eines solchen Feldes zum Einsatz kommt und somit für Suchmaschinen keine Rolle spielt. Aber auch bei der HTML-Umsetzung der Notes-Elemente
kommt es, wie in Abschnitt 3.2.2 beschrieben, zu Problemen, für die im folgenden Lösungsansätze präsentiert werden. Vor allem die Ansichten von Notes stellen mit ihren
Kategorien und Navigationslinks Probleme für Suchmaschinen dar.
Das spezifische URL-Kommando ExpandView von Domino bewirkt, daß alle Kategorien der Ansicht expandiert dargestellt werden, so daß sämtliche Links für den Spider
zugänglich sind. Damit wird jedoch nicht verhindert, daß der Spider auch die Links zum
Zuklappen der Kategorien erfaßt und verfolgt und somit die ursprüngliche Problematik
nicht behoben wird. Zudem wirkt es sich nachteilig auf die Benutzbarkeit aus, wenn der
Benutzer stets mit expandierten Ansichten arbeiten muß. Aufgrund dieser Nachteile ist
von dem Einsatz kategorisierter Ansichten im Zusammenhang mit Suchmaschinen abzuraten. Auch werden aufgrund der beschriebenen Problematik URLs, die den Ausdruck Expand enthalten, von einigen Suchmaschinen ignoriert19. Wie in Abschnitt 3.2.2
erläutert, tritt ein ähnliches Problem in Verbindung mit Sektionen auf. Auch hier gibt es
ein spezielles URL-Kommando ExpandSection, bei dem allerdings jede zu expandierende Sektion explizit angegeben werden muß. So öffnet z. B. das Kommando ExpandSection=1,2,3,2.1 die ersten drei Sektionen der ersten Ebene sowie die erste
Untersektion der zweiten Sektion. Daher ist es auf diese Weise nicht möglich, per URLKommando sämtliche Sektionen automatisch zu expandieren. Zwar existieren
@Command-Funktionen und LotusScript-Befehle, mit denen alle Sektionen expandiert
werden können, aber leider stehen diese nur beim Zugriff über einen Notes-Client zur
Verfügung, so daß sich für Sektionen keine geeignete Lösung finden läßt. Dies spielt für
NetFicient jedoch nur eine untergeordnete Rolle. Da auf Clientseite in der neuen Release auch für Autoren hauptsächlich Webbrowser zum Einsatz kommen sollen (vgl. Deutsche Bank AG 1999b, S. 24), stehen Sektionen als Designelement für Webautoren nicht
zur Verfügung.
Für die beschriebenen Störungen, die durch die automatisch erzeugten Navigationslinks
einer Ansicht verursacht werden, bietet sich folgender Lösungsansatz an. Durch den
Einsatz einer Ansichtsschablone kann die automatische Erzeugung der Links unter-
19
Die interne Suchmaschine dbsearch der Deutschen Bank ignoriert neben „Expand“ auch noch den Aus-
druck „OpenView“.
53
drückt werden. Bei jedem Aufruf einer Ansicht kontrolliert Domino, ob für diese Ansicht eine spezielle oder Standardschablone existiert, die für die Anzeige benutzt werden
soll. Eine derartige Schablone wird durch eine Maske mit dem vordefinierten Namen
„$$ViewTemplate for Ansichtsname“ generiert. Zur Anzeige der Ansicht muß diese
Maske ein Feld namens $$ViewBody enthalten. Zusätzlich können dieser Schablone
weitere Elemente hinzugefügt werden, um z. B. selbst Navigationsfunktionalitäten zu
implementieren, die nicht die angesprochenen Probleme aufweisen (vgl. Abschnitt
4.1.5). Allerdings lassen sich auch mit dieser Vorgehensweise nicht die durch Kategorien verursachten Schwierigkeiten beheben.
Mit dem in Release 5 von Notes/Domino neu hinzugekommenen Designelement Gliederung läßt sich ein weiterer Lösungsansatz der Ansichtsproblematik verwirklichen. Die
Ansicht, mit der in NetFicient die Navigationsleiste erzeugt wird, ist die einzige Ansicht, mit der die Benutzer und somit auch die Suchmaschinen direkten Kontakt haben.
Wie der Name schon sagt, eignen sich Gliederungen vorzüglich, um Seitenübersichten
oder Navigationsleisten zu realisieren. Wird zur Darstellung der Outlines für den Webzugriff HTML anstelle des dazu vorgesehenen Java-Applets verwendet, können die
Suchmaschinen über die so generierte Navigationsleiste die Website durchsuchen, vorausgesetzt sie können Framesets verarbeiten.
Die Verwendung einer speziellen Seite für Suchmaschinen stellt von den hier vorgestellten Ansätzen die flexibelste Lösung dar, da mit ihrer Hilfe die meisten angesprochenen Probleme umgangen werden können. Da dieser Lösungsansatz auch in den vorigen Abschnittem schon aufgegriffen wurde, konzentriert sich der nächste Abschnitt auf
die Realisierung einer derartigen Suchseite.
4.1.5 Implementation einer speziellen Suchseite
In den vorangegangenen Abschnitten wurde mehrfach eine spezielle Suchseite erwähnt.
Dabei ging es vor allem darum, wann eine derartige Seite sinnvoll ist und wie man den
Spider der Suchmaschine auf diese Seite lenkt. In diesem Abschnitt geht es nun um die
Umsetzung einer speziellen Suchseite in Domino, wobei mehrere Methoden denkbar
sind. Zum einen kann man über das spezifische Domino-URL-Kommando Openview&Start=1&Count=999999&ExpandView alle Dokumente in einer bereits ex-
54
pandierten Liste anzeigen.20 Probleme kann es bei dieser Methode jedoch mit größeren
Datenbanken geben, da hier sehr große HTML-Dateien übertragen werden müssen.
Auch zu beachten sind in diesem Zusammenhang die in Abschnitt 3.2.3 erwähnten Einstellungen in der Serverkonfiguration. Wird hier ein relativ niedriger Wert für die maximale Anzahl anzuzeigender Zeilen einer Ansicht eingetragen, kommt es zu den bereits
beschriebenen Problemen mit den speziellen Ansichtslinks „Next“ und „Previous“, die
automatisch angezeigt werden, wenn die Ansicht mehr Einträge aufweist, als Zeilen
angezeigt werden dürfen.
Eine Lösung für das gerade beschriebene Problem bietet folgender Ansatz. Als Suchseite wird eine spezielle Ansicht (Searchview) generiert, die nur eine einzelne Spalte
ohne Kategorien enthält. Als Wert für diese Spalte „berechnet“ man jeweils eine URL
für alle Seiten der Homepage. Zudem wird die Eigenschaft der Ansicht auf Pass Thru
HTML gesetzt und die Ansicht in eine Schablone eingebettet. Auf diese Weise wird
gewährleistet, daß Domino nicht automatisch die bereits erwähnten Ansichtslinks generiert. Ist die Anzahl der Zeilen aber größer als die maximal in der Serverkonfiguration
eingestellte, werden dadurch nicht alle Links in der Ansicht angezeigt. Dazu muß man
die beiden Links „Next“ und „Previous“ von Hand programmieren21 und diese in die
Ansichtsschablone für die Suchansicht (siehe Abschnitt 4.1.4) einfügen.
Nachteil der beiden vorgestellten Methoden ist jedoch, daß die Suchmaschinen innerhalb der Dokumente wieder auf Links stoßen und diese weiterverfolgen, womit sie wieder auf „normale“ Ansichten treffen können, die wieder die beschriebenen Probleme
aufweisen.
4.2 Unterstützung der Suchmaschinensoftware
Die unüberschaubare Größe der als Suchergebnis zurückgelieferten Trefferlisten beinhaltet, wie in Abschnitt 3.3 beschrieben, zwei unterschiedliche Probleme. Aus der Sicht
des Informationsanbieters liegt das Ziel darin, möglichst weit oben in den relevanten
Trefferlisten plaziert zu werden. Um dies zu erreichen, muß zum einen die korrekte
Einordnung der Webseiten gewährleistet werden, zum anderen müssen auch die Ran-
20
Auch wenn die reale Zahl der Dokumente von der Count-Anzahl abweicht.
21
Die Implementation dieser Links wird in Abschnitt 5.3 beschrieben.
55
kingverfahren der Suchmaschinen berücksichtigt werden. Diese beiden Aspekte werden
im folgenden Abschnitt detailliert dargestellt. Der daran anschließende Abschnitt befaßt
sich dann mit der zweiten Problematik, die aus der Sicht des Informationssuchenden
darin besteht, schnell Informationen zu finden und diese auch qualitativ bewerten zu
können. Dazu werden Anforderungen an ein leistungsfähiges und benutzerfreundliches
Suchinterface konzipiert und ihre Relevanz in der Praxis verdeutlicht.
4.2.1 Korrekte Einordnung der Seiten in den Trefferlisten
Je weiter oben eine Seite in der Trefferliste einer Suchmaschine angezeigt wird, um so
mehr Benutzer werden die Seite auch besuchen. Zudem ist es wichtig, daß die eigene
Seite nur im richtigen Kontext ausgesucht wird. Daher wird im folgenden zunächst auf
die Rankingverfahren der Suchmaschinen eingegangen, um anschließend, darauf aufbauend, Lösungsansätze zu entwickeln, mit denen ein gutes Ranking und die korrekte
Themenzuordnung der eigenen Seiten erreicht werden soll. Bezüglich der Rankingverfahren können an dieser Stelle jedoch nur einige allgemeine Vorgehensweisen aufgezeigt werden, von denen die einzelnen Suchmaschinen jedoch mehr oder weniger stark
abweichen (siehe Tabelle 5). Die genauen Methoden und Algorithmen der einzelnen
Suchmaschinen stellen ein gut gehütetes Geheimnis der Betreiber dar.
Alta
Vista
Excite
Northern
Light
Web
Crawler
Verity
-
Ja
-
Ja
Nein
-
Ja
Nein
Link Popularity
Nein
Ja
Ja
Nein
Ja
Nein
Ja
Nein
Meta Tags
Nein
Nein
Ja
Ja
Nein
Nein
Nein
Ja
Meta Refresh
Spam
OK
OK
Spam
OK
OK
OK
OK
Unsichtbarer
Text
Spam
OK
Spam
Spam
Spam
Spam
OK
OK
Kommentare
Nein
Nein
Ja
Nein
Nein
Nein
Nein
Nein
Stop-Wörter
Ja
Ja
Ja
Nein
Ja
Nein
Nein
Ja
Groß-/Kleinschreibung
Ja
Nein
Gemischt
Ja
Nein
Gemischt
Nein
Ja
Review
HotBot/ Infoseek Lycos
Inktomi
Tabelle 5: Faktoren, die das Ranking der Suchmaschinen beeinflussen
56
Die Plazierung und Häufigkeit der Schlagwörter ist ein wichtiges Indiz für das spätere
Ranking. Schlagwörter, die im Seitentitel und Head-Abschnitt stehen, werden von
Suchmaschinen stärker gewichtet als Schlagwörter im Body-Abschnitt. Auch dort wird
Schlagwörtern im oberen Bereich größere Bedeutung zugemessen als weiter unten gelegenen. Auch die Anzahl der Vorkommen eines Schlagwortes beeinflußt das Ranking
positiv. Dabei ist jedoch zu bedenken, daß die meisten Suchmaschinen zu häufige Wiederholungen als Täuschungsversuch (Search Engine Spamming) bewerten und die Seite
dann ignoriert wird.
Auch die Popularität einer Seite (engl. Link popularity) spielt bei den meisten Suchmaschinen eine Rolle (vgl. Tabelle 5). Berechnet wird die Popularität einer Seite anhand
der Anzahl von anderen Webseiten innerhalb des Indexes, die mit einen Link auf die
entsprechende Seite verweisen. Je „populärer“ eine Seite ist, desto besser schneidet sie
beim Ranking ab.
Meta-Tags sind spezielle Tags innerhalb des HEAD-Abschnitts (vgl. Abschnitt 2.1) und
gelten allgemein als die beste Einflußmöglichkeit auf das Ranking. Da aber jeder versucht, seine Seite so gut wie möglich zu verkaufen, kommt es oft vor, daß Schlagwörter
und Beschreibungen benutzt werden, die mit der eigentlichen Seite gar nichts zu tun
haben. Aus diesem Grund ignorieren mittlerweile einige Suchmaschinen diese MetaTags bzw. messen ihnen nicht mehr eine so große Bedeutung zu. Ein weiteres Problem
ist, daß bezüglich der Meta-Tags kein einheitlicher Standard besteht22. So benutzen einige Suchmaschinen spezielle Meta-Tags, die nur von ihnen selbst benutzt und verstanden werden. Hinzu kommt, daß diese oft von den Administratoren der Suchmaschinen
modifiziert werden. Ein Beispiel hierfür ist der im Intranet der Deutschen Bank benutzte
Tag „relevance“, welcher explizit von der internen Suchmaschine dbsearch unterstützt
wird (vgl. Deutsche Bank AG 1999, S. 8). Als Standard haben sich jedoch die MetaTags Description, Summary und Keywords etabliert (vgl. Tabelle 6 auf Seite 57).
Description und Summary werden dazu genutzt, eine kurze Zusammenfassung oder
Beschreibung des Seiteninhalts anzugeben. Die meisten Suchmaschinen geben diesen
Eintrag auch als Information in der Trefferliste mit an, wobei jedoch nur die ersten 255
Zeichen berücksichtigt werden. Mit dem Meta-Tag Keywords können mehrere
22
Eine Übersicht der üblichen Meta-Tags liefert Sullivan (1998b).
57
Schlagwörter angegeben werden, die von den Suchmaschinen stärker berücksichtigt
werden als durch Volltextindizierung generierte Schlagwörter.
Einige Suchmaschinen führen auch eine Statistik über die vom Benutzer ausgewählten
Seiten (Review). Je häufiger dabei eine Seite angeklickt wird, um so besser schneidet sie
beim nächsten Ranking ab.
Standardmäßig geben die hier untersuchten Suchmaschinen als Suchergebnis die ersten
10, maximal 20 gefundenen Seiten zurück. Aufgrund der bereits beschriebenen Problematik kann je nach Thematik ein Ranking unter den ersten 20 Treffern nicht garantiert
werden. Indem man aber Spamming vermeidet und die Benutzer in NetFicient bei den
für Suchmaschinen relevanten Einträgen unterstützt, kann man erreichen, daß die Seiten
von den Suchmaschinen zu den richtigen Themenbereichen eingeordnet und adäquate
Informationen in der Trefferliste angezeigt werden und außerdem eine möglichst hohe
Wahrscheinlichkeit für ein gutes Ranking erzielt wird.
Alta
Vista
Excite
HotBot/
Inktomi
Infoseek
78
70
115
70
60
„No title“
„Untitled“
URL
Erste Zeile
Description/
keywords
Beide
Description
Beide
Länge der
Beschreibung
150
395
249
Titellänge
Kein Titel
Lycos Northern
Light
Web
Crawler
Verity
80
60
Variabel
Erste
Zeile
-
URL
Variabel
Beide
Keine
Keine
170-240
135200
150-200
Description Variabel
395
Variabel
Tabelle 6: Faktoren zur Beeinflussung der Trefferliste
Die richtige Einordnung der eigenen Webseiten seitens der Suchmaschinen wird durch
passende Einträge im HTML-Header bewerkstelligt. Vor allem die bereits angesprochenen Meta-Tags Description, Summary und Keywords spielen dabei eine gewichtige
Rolle, aber auch der Titel der Seite sollte geeignet gewählt werden. Daher gilt es, die
Benutzer von NetFicient bei der Eingabe dieser Einträge zu unterstützen. Ein Ansatz
wäre es, die entsprechenden Felder automatisch berechnen zu lassen. So ist es sicher
kein großer Programmieraufwand, die ersten Zeilen aus dem Inhalt der Seite in das Description-Feld zu schreiben oder nach bestimmten Schlagwörtern zu suchen und diese
dann in das Keywords-Feld einzutragen. Mit dieser Vorgehensweise würde der Benutzer zwar am stärksten entlastet, sie beinhaltet aber einen entscheidenden Nachteil. Der-
58
artig berechnete Einträge können zum einen nie so gut werden wie manuell erstellte,
zum anderen nimmt man auf diese Weise der Suchmaschine nur die Arbeit ab, da die
Suchmaschinen, wie in Tabelle 5 und Tabelle 6 zu sehen, ähnlich vorgehen, wenn diese
Informationen nicht angegeben werden. Wichtiger ist es daher, die Benutzer durch geeignete Hilfetexte und Schulungen auf die Problematik hinzuweisen und somit zu motivieren, geeignete Einträge vorzunehmen. Auch sollte ein zusätzlicher Arbeitsschritt im
Redaktions-Workflow hinzugefügt werden, in dem die entsprechenden Einträge noch
mal zu überprüfen und gegebenenfalls zu korrigieren sind. Einige Modifikationen können dabei auch automatisiert werden. Vor allem sollten automatisch verschiedene
Schreibweisen der eingegebenen Schlagwörter generiert werden, wie z. B. Umlaute zu
ersetzen und Groß- und Kleinschreibung hinzuzufügen, da die meisten Suchmaschinen
diese unterscheiden, wie auch das Beispiel in Abschnitt 3.3 zeigt. Auch sogenannte
Stopwörter (siehe Tabelle 5) sollten vermieden werden. Unter Stopwörtern versteht man
im Zusammenhang mit Suchmaschinen Begriffe, die aufgrund ihrer Häufigkeit von den
Suchmaschinen ignoriert werden (vgl. Sullivan 1999). So wird beispielsweise das Wort
„Web“ im Begriff „Web Developer“ ignoriert. Unterstützen kann man die Benutzer in
dieser Hinsicht, indem man sie bei der Eingabe auf Stopwörter aufmerksam macht.
Auch können automatisch die Begriffe in Anführungszeichen eingeschlossen oder durch
Synonyme ersetzt werden.
4.2.2 Konzeption eines leistungsfähigen Suchinterfaces
Bei der Entwicklung eines leistungsfähigen Suchinterfaces müssen zwei Ziele im Vordergrund stehen. Zum einen muß den Benutzern eine Vielzahl von Funktionalitäten zur
Verfügung gestellt werden, mit denen exaktere Suchanfragen formuliert werden können, um so die Anzahl der Suchergebnisse einzuschränken und die Qualität der gefundenen Informationen abschätzbar zu machen. Zum anderen darf die Benutzerfreundlichkeit nicht außer acht gelassen werden, um unerfahrenen Benutzern die Suche zu
erleichtern und geübte Anwender bei leistungsfähigen Suchanfragen zu unterstützen.
Daher werden in diesem Abschnitt zwei Aspekte diskutiert. Zunächst wird eine Liste
von benötigten Funktionen erstellt, darauf aufbauend werden Mittel zu einer benutzerfreundlichen Implementation dieser Funktionen dargestellt. Dabei lassen sich die hier
betrachteten Methoden in zwei grundlegende Bereiche differenzieren: Funktionen, mit
denen die Suche präzisiert werden kann, und Funktionen zur Beeinflussung der verwendeten Rankingverfahren bzw. Darstellung der Trefferliste.
59
4.2.2.1 Obligatorisch zu unterstützende Funktionalitäten
Um die in Abschnitt 3.3 beschriebene große Anzahl an Suchergebnissen auf einen überschaubaren Anteil relevanter Treffer einzugrenzen, müssen dem Benutzer Funktionen
zur Verfügung gestellt werden, mit denen es möglich ist, den Suchbegriff zu präzisieren
bzw. den Suchraum einzugrenzen. Eine einfache Form zur Präzisierung des Suchbegriffes stellt die Verknüpfung mehrerer Begriffe durch logische Operatoren dar (vgl.
Tabelle 7). Eine weitere Methode, um die Suchergebnisse einzuschränken, ist die Verwendung von Phrasen, d. h. durch das Umschließen von Wörten mit Anführungszeichen (z. B. „Web Developer“), wird die Suchmaschine veranlaßt, nach genau diesem
Ausdruck zu suchen. Auch mit Hilfe von Groß- und Kleinschreibung läßt sich der
Suchbegriff genauer bestimmen. So suchen die meisten Suchmaschinen bei kleingeschriebenen Suchbegriffen nach allen Schreibweisen, während bei der Verwendung von
Großbuchstaben nach der genauen Schreibweise gesucht wird.
Ausdruck
Symbol
Beschreibung
AND
&
Findet nur Webseiten, die alle angegebenen Begriffe enthalten.
OR
|
Findet alle Webseiten, die mindestens einen der angegebenen Begriffe
enthalten.
AND NOT
!
Filtert Webseiten aus, die den angegebenen Begriff enthalten.
„Gruppierung“
()
Mit Klammerung können komplexe Ausdrücke gruppiert werden.
NEAR
~
Findet Webseiten, in denen die beiden angegebenen Begriffe nah aneinander stehen.23
Tabelle 7: Logische Operatoren für Suchanfragen (vgl. Altavista 1999)
Die 2. Möglichkeit, die Anzahl der Suchergebnisse zu reduzieren, stellt die Eingrenzung
des Suchraums dar. Eine gängige Variante ist dabei der Einsatz von diversen Filtern,
wie z. B. Sprach- oder Datumsfilter. Des weiteren bieten die meisten Suchmaschinen
eine Abgrenzung des Suchfokus an, d. h. die Suchmaschine kann angewiesen werden,
nur bestimmte Bereiche zu durchsuchen. Auf der obersten Ebene werden dabei Web
und Intranet unterschieden, die zusammen den gesamten Suchraum darstellen. Diese
beiden Bereiche lassen sich wiederum durch ihre eigene Struktur unterteilen, beim Web
in Domänen (z. B. .de) und Subdomänen (z. B. uni-paderborn.de), im Intranet dement-
23
Z. B. beträgt der Abstand bei Altavista maximal 10 Wörter (vgl. Altavista 1999).
60
sprechend Unternehmenstöchter, Standorte und die Homepages der Abteilungen. Auf
der untersten Ebene steht dann schließlich die aktuelle Web- bzw. Intranetseite (vgl.
Abb. 17.) Zusätzlich macht es Sinn, die Suche auch auf einzelne HTML-Abschnitte der
Webeiten zu beschränken. Tabelle 8 zeigt beispielhaft die Möglichkeiten von Altavista
(vgl. Sonnenreich/Macinta 1998, S. 33).
Gesamter
Suchraum
World Wide Web
Intranet
Domaine
Töchter
Subdomaine
Standorte
Host
Abteilung
Aktuelle
Webseite
Abb. 17: Räumliche Abgrenzung des Suchfokus
Ausdruck
Beschreibung
Anchor:text
Findet Webseiten, die den angegebenen Text innerhalb eines Hyperlink-Tags
enthalten.
Applet:class
Findet Webseiten, die das angegebene Java-Applet enthalten.
Domain:domainname Beschränkt die Suche auf die angegebene Domain.
Host:name
Beschränkt die Suche auf den angegebenen Server.
Image:filename
Findet Webseiten, die Bilder mit dem angegebenen Dateinamen enthalten.
Link:URLtext
Findet Webseiten, die einen Link auf die angegebene URL enthalten.
Text:text
Ignoriert bei der Suche URLs und HTML-Tags.
Title:text
Beschränkt die Suche auf Webseiten mit dem angegebenen Begriff im Titelabschnitt des HTML-Codes.
URL:text
Findet Webseiten, die den angegebenen Begriff in ihrer URL enthalten.
Tabelle 8: Ausdrücke zur Abgrenzung des Suchfokus (vgl. Altavista 1999)
61
Neben dieser „räumlichen“ Einschränkung kann auch eine themenspezifische Abgrenzung vorgenommen werden, z. B. in Themengebiete wie Wirtschaft, Technologie,
Sport, Politik etc. Die Schwerpunkte können dabei je nach Zielsetzung unterschiedlich
sein. So ist es für das hier untersuchte Unternehmen sicherlich sinnvoll, den Themenkomplex Wirtschaft weiter aufzugliedern (z. B. Märkte, Börse usw.), und dafür auf weniger relevante Bereiche zu verzichten.
Da die Trefferliste auch bei hinreichender Präzisierung des Suchbegriffes noch sehr
groß werden kann, ist es notwendig, das Vorgehen beim Ranking manipulieren zu können. So stellt z. B. Lycos dem Benutzer die Möglichkeit zur Verfügung, die Priorität
von gewissen Kriterien beim Ranking zu beeinflussen. Dabei können die Werte low,
default und high für die folgenden Merkmale vergeben werden:
-
Alle gesuchten Begriffe enthalten
-
Häufigkeit der gesuchten Begriffe
-
Stärkere Gewichtung des Textanfangs
-
Nähe der gesuchten Begriffe
-
Stärkere Gewichtung des Seitentitels
-
Exakte Reihenfolge der gesuchten Begriffe.
Zudem sollte es dem Benutzer ermöglicht werden, Einfluß auf die Darstellung der Trefferliste zu nehmen, indem er z. B. bestimmen kann, wie viele Treffer angezeigt werden
sollen, ob nur der Titel oder auch eine kurze Beschreibung geliefert werden soll und
ähnliches.
4.2.2.2 Benutzerfreundliche Umsetzung der benötigten Funktionen
Wurden im letzten Abschnitt die benötigten Funktionen eines leistungsfähigen Suchinterfaces vorgestellt, wird nun darauf eingegangen, wie diese dem Anwender in einer
benutzerfreundlichen Weise präsentiert werden können. Dabei werden jedoch lediglich
einige wichtige Aspekte anhand von praktischen Beispielen erläutert. Ein ausführlicheres Eingehen auf Themengebiete wie Software-Ergonomie, Benutzerschnittstellen oder
Systemgestaltung würde an der Zielsetzung dieser Arbeit vorbeigehen. Der interessierte
Leser wird diesbezüglich auf Keil-Slawik (1997) und Deutsches Institut für Normung
(1996) verwiesen.
62
Wichtig bei der Realisierung eines leistungsfähigen und benutzerfreundlichen Suchinterfaces ist es, daß sowohl erfahrene Benutzer als auch Laien damit umgehen können.
Daher ist es notwendig, zwei verschiedene Suchmodi anzubieten: einen „normalen“
Suchmodus für Gelegenheitsnutzer sowie einen Expertenmodus, der komplexe Suchanfragen für erfahrene Benutzer zur Verfügung stellt. So reicht im normalen Modus die
Möglichkeit zur Eingabe von Suchbegriffen meist vollkommen aus. Idealerweise sollte
dabei auch die Eingabe von Fragen oder Sätzen aus dem normalen Sprachgebrauch unterstützt werden. Aber auch im Expertenmodus darf die Suchanfrage nicht nur über
komplizierte Ausdrücke möglich sein, sondern auch über ein intuitiv zu bedienendes
Interface, d. h. die wichtigsten Funktionen müssen durch grafische Schnittstellen auswählbar sein, ohne den Benutzer dabei durch eine zu große Funktionsvielfalt zu verwirren. Als Beispiel für eine gelungene Umsetzung sei hier das Interface von Infoseek in
Abb. 18 angegeben.
Abb. 18: Andvanced Search von Infoseek
Neben dem reinen Interface können auch zusätzliche Funktionen die Suche vereinfachen. Gerade bei der Suche im WWW, aber auch im globalen Intranet, ist eine Funktion
zur Übersetzung der wichtigsten Sprachen in die jeweilige Muttersprache (z. B. der Babelfish von Altavista) von großer Wichtigkeit, um alle gefundenen Informationen nutzen zu können. Auch eine Suche nach ähnlichen Begriffen oder Synonymen kann unerfahrenen Benutzern helfen, den geeigneten Suchbegriff zu finden. Für die häufige Nutzung ist das Anlegen von Profildokumenten sinnvoll, mit denen jeder Benutzer grundle-
63
gende Einstellungen zur schnellen Wiederverwendung abspeichern kann. (z. B. der Custom search folder von Northern Light).
4.3 Sicherheitsaspekte
Innerhalb einer Website kann es Bereiche geben, die nicht für den Zugriff von Externen
bestimmt sind, bzw. auf die Spider von Suchmaschinen nicht zugreifen sollen. Auch
kann es in manchen Fällen sinnvoll sein, nur bestimmte Suchmaschinen auszugrenzen
(z. B. nur die interne Suchmaschine zuzulassen, während externe ausgeschlossen werden). Für dieses Problem haben sich im WWW zwei vom Ansatz her unterschiedliche
Standardverfahren durchgesetzt, die auch von allen externen Suchmaschinen unterstützt
werden (siehe Tabelle 9). Lediglich Verity versteht den Meta-Tag Robots nicht vollständig24. Am weitesten verbreitet ist das Erstellen einer ASCII-Datei im HomeVerzeichnis des Webservers mit Namen robots.txt. Mit Hilfe dieser Datei können Spider daran gehindert werden, ganze Sites, ein bestimmtes Verzeichnis und dessen Unterverzeichnisse und sogar eine einzelne Datei zu indizieren. Dabei können:
-
alle Spider,
-
alle Spider außer den in der Datei aufgeführten Spidern oder
-
nur die aufgeführten Spider
ausgeschlossen werden. Diese Methode wird von fast allen gängigen Suchmaschinen
akzeptiert. Problematisch ist bei dieser Vorgehensweise jedoch, diese Datei aktuell zu
halten, da Webautoren normalerweise keinen Zugriff auf diese Datei haben sollten.
Passwort geschützte Seiten
Robots.txt
Meta Ro-
bots
Alta
Vista
Excite
HotBot/
Inktomi
Infoseek
Lycos Northern
Light
Web
Crawler
Verity
Nein
Ja
Nein
Ja
Ja
Ja
Nein
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Noindex
Tabelle 9: Unterstützte Sicherheitsstandards
24
In der nächsten Version soll auch Verity diese Funktion voll unterstützen.
64
Aufgrund dieser Problematik wurde eine weitere Methode mit Hilfe des Meta-Tags Robots eingeführt. Der Robots-Meta-Tag kann mit folgenden Parametern aufgerufen
werden: All, None, Index, NoIndex, Follow, NoFollow, wobei All als DefaultWert gesetzt wird. Während None den kompletten Zugriff auf die Seite verhindert, wird
mit NoIndex zwar die Indizierung der Seite verboten, die Links in der Seite werden
aber weiter verfolgt. Analog ermöglicht NoFollow das Indizieren der Seite, verhindert
aber, daß die Links weiterverfolgt werden. Auf diese Weise kann jeder Benutzer die
Rechte selber setzen (in Absprache mit dem zuständigen Webredakteur). Zudem können
diese Werte innerhalb der Dokumente ohne Probleme repliziert werden. Der entscheidende Nachteil dieser Methode ist jedoch, daß man keine differenzierte Ausgrenzung
von Suchmaschinen vornehmen kann. Entweder sind alle Suchmaschinen betroffen oder
keine.
Eine weitere Option wäre es, die Sicherheitstechnologien von Domino zu nutzen.
Grenzt man den Zugriff auf sensitive Bereiche mit Hilfe der Access Control List (ACL)
für autorisierte Benutzer ab, können Suchmaschinen nicht darauf zugreifen. Es ist allerdings bei Websites nicht möglich, nur Suchmaschinen auszuschließen, da damit automatisch alle anonymen Benutzer auch keinen Zugriff mehr haben, was sicher nicht im
Sinne einer Webpräsenz ist. Andererseits können die meisten Suchmaschinen (siehe
Tabelle 9 auf Seite 63) auch durch Passwort geschützte Seiten durchsuchen, vorausgesetzt, es wird ihnen ein entsprechender Benutzername mit Passwort zugeteilt. Sinn kann
diese Vorgehensweise bei kostenpflichtigen Seiten machen, indem die „Kunden“ über
die Suchmaschinen auf das Angebot aufmerksam gemacht werden und sich bei Interesse dann registrieren lassen können.
Lösungskonzept zur Integration von Suchmaschinen in NetFicient
65
5 Lösungskonzept zur Integration von Suchmaschinen in
NetFicient
Im letzten Kapitel wurden verschiedene Lösungsansätze präsentiert und ihre jeweiligen
Vor- und Nachteile diskutiert. Ziel dieses Kapitels ist es nun, die einzelnen Ansätze zu
einer umfassenden Lösung zu integrieren, um so ein Konzept für die Unterstützung von
Suchmaschinen in NetFicient zu entwickeln. Gemäß der in Abschnitt 1.2 definierten
Zielsetzungen liegt der Schwerpunkt dabei auf der Unterstützung des Spiders und der
korrekten Einordnung der Webseiten durch den Indexer unter Berücksichtigung der
speziell durch NetFicient gegebenen Anforderungen. Die Umsetzung eines wie in Abschnitt 4.2.2.2 konzipierten Suchinterfaces spielt daher in diesem Kapitel keine Rolle
mehr.
5.1 Lösungsansatz und Vorgehensweise
Das in diesem Kapitel entwickelte Lösungskonzept umfaßt alle im Zusammenhang mit
Spider und Indexer beschriebenen Probleme. Um die korrekte Erfassung und Einordnung der Seiten zu gewährleisten, wird zunächst die in Abschnitt 4.1.1 erläuterte Manipulation der HTTP-Header in das Lösungskonzept integriert. Zudem werden die für die
Suchmaschinen relevanten Meta-Informationen automatisch aus Benutzereingaben generiert und als Meta-Tags in den HTML-Head geschrieben..
Darauf folgend wird auf Basis der in Abschnitt 4.1.5 beschriebenen Searchview ein
Suchbaum generiert, der es dem Spider ermöglicht, alle mit NetFicient publizierten
Seiten von einem beliebigen Startpunkt aus zu erreichen. Zusätzlich wird eine Trennung
des Seiteninhalts von den dazugehörigen Meta-Informationen vorgenommen, um Informationen in verschiedenem Kontext darstellen zu können und um somit die von NetFicient gestellten Anforderungen zu erfüllen.
In den folgenden Abschnitten werden die hier nur kurz vorgestellten Ansätze detailliert
beschrieben und ihre Implementation in Notes/Domino anhand der Entwicklung eines
einfachen Prototyps erläutert, wobei jeweils auf die wichtigsten Punkte eingegangen
wird. Die komplette Dokumentation des Prototyps ist in Anhang 9.3 zu finden.
Abschließend wird das entwickelte Lösungskonzept in einem Test (Proof of Concept)
mit der internen Suchmaschine dbsearch verifiziert. Grundlage für diese Verifikation
66
bildet der bereits erwähnte Prototyp, der basierend auf dem hier vorgestellten Lösungsansatz entwickelt wird.
5.2 Programmierung der Meta-Informationen im HTTP-Header und
HTML-Head
Um die korrekte Erfassung und Einordnung der einzelnen Webseiten zu erreichen, müssen zwei Aspekte berücksichtigt werden:
1. Durch korrekt gesetzte Werte für Expires und Last-Modified im HTTP-Header
wird es ermöglicht, daß die Seite überhaupt indiziert und auf dem aktuellen Stand
im Index der Suchmaschine gehalten wird (vgl. Abschnitt 3.1.1).
2. Die richtige Zuordnung der indizierten Seiten wird mittels der entsprechenden MetaTags im HTML-Head erreicht (siehe Abschnitt 4.2.1).
Während das Last-Modified-Datum einfach über die @Funktion @Modified von
Notes berechnet wird, kann das Expires-Datum durch zwei unterschiedliche Methoden gewonnen werden. Zum einen kann es durch die Eingabe des Benutzers gesetzt
werden, zum anderen besteht die Möglichkeit, jede Webseite automatisch mit einer vordefinierten Gültigkeitsdauer zu versehen. Für den entwickelten Prototyp wird der Einfachheit halber die zweite Alternative gewählt. Zudem werden die HTTP-Header nicht,
wie in Abschnitt 4.1.1 vorgestellt, als Servlet oder Agent geschrieben, sondern es wird
in Absprache mit Herrn Priewe von der Deutschen Bank AG die Lösung über den
HTML-Tag HTTP-EQUIV gewählt, da diese zum einen einfacher zu implementieren ist
und zum anderen gerade ihre Einfachheit zu besser überschaubaren Ergebnissen im abschließenden Proof of Concept führt.
Zur Generierung der Meta-Tags im HTML-Head müssen die Informationen über entsprechende Felder in der Notes-Maske eingegeben werden. Wie in Abschnitt 4.2.1 begründet, spielen dabei vor allem die beiden Einträge Beschreibung und Schlüsselwörter
(siehe auch Abb. 19 auf S. 67) eine wichtige Rolle, da aus diesen Werten die Meta-Tags
Description/Summary und Keywords berechnet werden. Daher sind diese beiden
Felder auch als Mußfelder definiert, d. h. hier müssen vom Benutzer Werte eingetragen
werden. Bei der Eingabe der Schlüsselwörter wird der Benutzer unterstützt, indem er
nur aus einer Liste vordefinierter Begriffe auswählen und keine eigenen Eingaben machen kann. Auf diese Weise wird gewährleistet, daß die Webseite später in den richti-
67
gen Kontext eingeordnet wird. Zudem wird so die Konformität der Schlüsselwörter innerhalb einer Website erreicht.
Abb. 19: Maske zur Eingabe der Informationen für die Suchmaschine
Zusätzlich können die Benutzer noch angeben, ob diese Seite überhaupt indiziert und
wenn ja, mit welcher Wichtigkeit sie von der internen Suchmaschine eingestuft werden
soll (siehe Abb. 19). Sind die Informationen durch den Benutzer eingegeben, können
daraus die entsprechenden Meta-Tags berechnet und diese zusammen mit dem MetaTag HTTP-EQUIV in den HTML-Head geschrieben werden. Dazu wird die in Abb. 20
angegebene Formel in die Maskenmethode HTML Head Content geschrieben.
_keywords:=@Implode(keywords; "," );
_lastmodified:=@Text(@Modified);
"<META name=\"robots\" content=\"None\">"+@Char(10)+
"<META name=\"description\" content=\""+Description+"\">" +
@Char(10)+
"<META name=\"keywords\" content=\""+_keywords+"\">"+@Char(10)+
"<META name=\"relevance\" content=\""+relevance+"\">"+@Char(10)+
"<META name=\"last_modified\" content=\""+_lastmodified+"\">"+@Char(10)+
"<META name=\"author\" content=\""+Autor+"\">"
Abb. 20: Programmierung des HTML-Head in Notes
68
5.3 Generierung eines Suchbaumes zur Unterstützung der Spider
Das in diesem Abschnitt beschriebene Konzept zielt auf die Erfaßbarkeit der Webseiten
durch den Spider, d. h., unabhängig von den verwendeten Methoden und Technologien
wie Framesets, Java-Applets etc. (siehe auch Abschnitt 3.1.2) soll es dem Spider möglich sein, alle Webseiten innerhalb einer Site von einem beliebigen Startpunkt aus zu
erreichen. Ziel ist es, daß der Spider die Website auf einem vorbestimmten Weg entlang
eines Suchbaums durchwandert (vgl. Abb. 21). Wichtig dabei ist die Kontrolle des Spiders, so daß er nicht aus dem Suchbaum ausbricht und in für ihn problematische oder
verbotene Bereiche gelangt. Auch soll auf diese Weise verhindert werden, daß der Spider eine Webseite über verschiedene Domino-URLs findet und diese dadurch mehrfach
indiziert wird.
Spider
Legende
Webseite
Suchseite
Weg des Spiders
durch den
Suchbaum
Abb. 21: Lenkung des Spiders durch den Suchbaum
69
Als Basis für die Generierung eines derartigen Suchbaums dient die in Abschnitt 4.1.5
dargestellte Suchansicht. Wie dort bereits beschrieben, enthält diese spezielle Ansicht
nur eine Spalte, in der HTML-Links für alle Seiten innerhalb der Datenbank berechnet
werden. Abb. 22 zeigt die entsprechende Spaltenformel, wobei vereinfachend davon
ausgegangen wird, daß die Datenbank im Root-Verzeichnis des Domino-Servers liegt.
"<A HREF=\"/"+@Subset(@DbName;-1)+"/Search/"
+@Text(@DocumentUniqueID)+"?OpenDocument\">"+Titel+"</A>"
Abb. 22: Berechneter Link für die Suchansicht
Um den Weg des Spiders zu kontrollieren, wird der Meta-Tag Robots in allen
Webseiten auf NoFollow gesetzt. Damit der Spider aber, wie in Abb. 21 illustriert,
auch auf andere Datenbanken gelenkt wird, müssen in der Suchansicht zusätzliche
Links enthalten sein, die auf diese Datenbanken verweisen. Dazu wird eine spezielle
Maske benutzt, die nur ein Feld für den entsprechenden Link enthält, welcher in der
Suchansicht mit angezeigt wird.
Wie in Abschnitt 4.1.5 dargelegt, wird zur Anzeige der Suchansicht eine Standardschablone verwendet, um so zu verhindern, daß Domino automatisch die speziellen Ansichtslinks generiert, welche für den Spider mehrere Probleme darstellen (vgl. Abschnitt
3.2.2). Damit aber unabhängig von der Konfiguration des Domino-Servers (vgl. Abschnitt 3.2.3) alle in der Ansicht berechneten Links dem Spider zugänglich sind, darf in
der Ansicht jeweils nur eine begrenzte Anzahl von Links angezeigt werden, und es muß
ein zusätzlicher Link hinzugefügt werden, über den der Spider zu den restlichen Links
in der Ansicht gelangen kann. Zur Manipulation der Anzahl angezeigter Zeilen in einer
Ansicht stellt Domino den Entwicklern das spezifische URL-Kommando ?OpenView,
zur Verfügung, welches mit den beiden Parametern &start=xx&count=yy aufgerufen
werden kann. Dabei gibt start die erste anzuzeigende Zeile an, und count definiert,
wie viele Zeilen angezeigt werden sollen. Hängt man also an die URL, über die der Spider auf die Suchseite gelenkt wird, beispielsweise ?OpenView&Start=1&Count=100
an, braucht nun nur noch ein Link generiert werden, der die jeweils nächsten hundert
Links anzeigt. Ein solcher Link läßt sich wie folgt zusammensetzen. Zunächst werden
70
die benötigten Informationen mit Hilfe von folgenden CGI-Variablen eingelesen (vgl.
Lotus Development Corporation 1999b, S. 498-502):
-
Path_Info:
liefert den Pfad, in dem die aktuelle Seite auf dem Server liegt.
-
Query_String:
liefert den Teil der URL, der hinter einem „?“ steht.
Während mit der ersten CGI-Variablen die URL für die Suchansicht ermittelt wird,
können über den Wert von Query_String die neuen Parameter für start und count
ermittelt werden, um so den Link zu generieren (vgl. Abb. 23). Zusätzlich muß noch die
Gesamtanzahl der Links mit dem aktuellen start-Wert verglichen werden, um eine
Endlosschleife (vgl. Abschnitt 3.2.2) zu vermeiden.
_path:=@Subset(@Explode(Path_Info;"?");1);
_query:=Query_String;
_paramlist:=@Subset(@Explode(_query;"&");-2);
_startstring:=@Subset(_paramlist;1);
_countstring:=@Subset(_paramlist;-1);
_start:=@TextToNumber(@Right(_startstring;@Length(_startstring)6));
_count:=@TextToNumber(@Right(_countstring;@Length(_countstring)6));
_max:=@Elements(@DbColumn( ""; ""; "help"; 1 ));
@If(_start +_count > _max;"";
"<A HREF=\"/" + @Text(_path) + "/Search?Openview&Start=" +
@Text( _start+_count) +"&Count="+@Text(_count)+"\">Next</A>")
Abb. 23: Quelltext für den Next-Link der Suchansicht
Schließlich muß noch gewährleistet werden, daß der Spider direkt auf die Suchansicht
verwiesen wird. Dazu wird im Hauptdokument des Framesets im NoFrame-Bereich
(vgl. Abschnitt 4.1.2) ein Link auf die Suchseite eingefügt. Für die Frames wird dabei
jeweils der Robots-Tag auf None gesetzt, so daß der Link auf die Suchseite den einzigen weiterführenden Weg für den Spider darstellt.
Zur Vervollständigung der Lösung wird noch der Robots-Tag auf der Standardschablone für die Suchansicht auf NoIndex gesetzt, damit sie nicht von der Suchmaschine
indiziert wird und Benutzer auf diesem Wege auf diese für sie nicht zugängliche Seite
gelangen können. Denkbar ist auch eine Erweiterung dieser Lösung, indem man auf
Basis des von Domino geführten Database Catalogue eine Startseite für Suchmaschi-
71
nen generiert, mit deren Hilfe der Spider dann durch die gesamte Domäne wandern
kann.
Somit ist die Erfassung der Seiten durch den Spider gesichert. Der anschließende Abschnitt beschäftigt sich nun mit der Lösung von Problemen, die speziell durch die Anforderungen von NetFicient gegeben sind.
5.4 Trennung von Seiteninhalt und Meta-Informationen
Das in den beiden vorigen Abschnitten entwickelte Konzept gewährleistet die Erfassung
aller Webseiten durch den Spider und die anschließende korrekte Einordnung der Seiten
durch den Indexer. Im folgenden wird nun das Konzept dahingehend erweitert, daß die
spezifischen Anforderungen von NetFicient Berücksichtigung finden. Diese Kernanforderungen machen es im wesentlichen notwendig, daß eine Webseite bzw. deren Inhalt
in mehrfachem Kontext von der Suchmaschine erfaßt werden kann. Um dies zu gewährleisten, wird eine Trennung des reinen Inhalts von den dazugehörigen MetaInformationen vorgenommen. Zu diesen Meta-Informationen gehören:
-
Informationen zur Indizierung durch die Suchmaschine (z. B. Stichwörter, Wichtigkeit etc.).
-
Informationen zum zugehörigen Navigationskontext.
-
Sonstige Informationen (z.B. auszuführende Scripte/Applets).
Dabei muß die Trennung nicht in allen Fällen strikt sein. So macht es z. B. für die zu
verwendenden Stichwörter im Meta-Tag KEYWORDS Sinn, diese aufzuteilen in rein inhaltsbezogene Stichwörter, die immer mit der Seite angezeigt werden sollen, und eher
kontextbezogene Stichwörter, die nur in einem bestimmten Zusammenhang (z. B. einer
bestimmten Homepage) angezeigt werden sollen. Die Informationen zum Navigationskontext geben zusätzlich das jeweils anzuzeigende Frameset an. Eine Umsetzung der
von NetFicient geforderten Multiframe-Funktionalität wäre nur mit sehr hohem Aufwand zu realisieren..
Die kontextabhängigen Informationen werden dabei jeweils in der entsprechenden
Homepage-Datenbank gespeichert. Dazu wird eine spezielle Maske erzeugt, mit deren
Hilfe ein Datenbankprofil erstellt werden kann, welches die Informationen in geeigneter
Form speichert. Für den Prototyp werden hier Links auf die beiden Frames der Datenbank sowie eine Textliste mit den spezifischen Schlüsselwörtern implementiert. Wird
72
nun eine Webseite aus einer anderen Datenbank heraus referenziert, wird mit Hilfe einer
speziellen Maske ein Referenzdokument in der Datenbnak der Webseite angelegt, welches den Namen der referenzierenden Datenbank und die DocumentID der entsprechenden Webseite speichert. Diese Referenzdokumente werden dann über die View Selection
Formular in die Suchansicht aufgenommen. Zudem wird die in Abb. 22 gezeigte Formel durch eine @If-Anweisung erweitert, so daß im Falle eines Referenzdokumentes
der entsprechende Datenbankname als Parameter an die URL angehängt wird. Die
Auswertung dieses URL-Parameters geschieht dabei analog zu dem in Abschnitt 5.3
beschriebenen Next-Link über die CGI-Variable Query_String. Mit Hilfe des Datenbanknamens können dann über @DbLookup-Anweisungen die Meta-Informationen hinzugeladen werden. Die Implementation dieser Funktionalität wird über eine zusätzliche
Maske realisiert, welche mit der Form Formula der Suchansicht automatisch zur Anzeige benutzt wird.
Durch die Verwendung von URL-Parametern wird zugleich der Effekt erreicht, daß die
Seite mehrfach von der Suchmaschine erfaßt wird, womit die angestrebte Funktionalität
gewährleistet wird.
5.5 Verifikation des entwickelten Konzeptes
Zum Abschluß dieses Kapitels muß nun noch das entwickelte Konzept anhand eines
praktischen Tests auf seine Richtigkeit und Praxistauglichkeit hin untersucht werden.
Dazu wird mit der internen Suchmaschine dbsearch auf Basis des implementierten Prototyps ein sogenannter Proof of Concept durchgeführt. Die Vorgehensweise und die
Testumgebung werden im folgenden Abschnitt beschrieben, daran anschließend werden
dann die Ergebnisse des Tests präsentiert. Dabei wird an dieser Stelle nur auf die
Merkmale und Ergebnisse des letzten und entscheidenden Testlaufs eingegangen. Die
Probleme und Erkenntnisse aus den ersten Versuchen sind ebenso den Protokollen in
Anhang 9.4.1 zu entnehmen wie die verwendete Konfiguration des Spiders.
5.5.1 Testumgebung und Vorgehensweise
Ziel des Proof of Concepts ist die Bestätigung des in dieser Arbeit entwickelten Lösungskonzepts. Dazu wird auf Basis des Prototypen eine Datenbank mit mehreren Dokumenten und Seiten erstellt, die dann von der internen Suchmaschine Verity (vgl. Ab-
73
schnitt 2.5) durchsucht wird. Aufgrund einiger technischer Eigenschaften von Verity25
sind jedoch zuvor einige Anpassungen am Prototyp notwendig. Da Verity den NoFollow-Parameter des Robots-Tags nicht versteht (siehe auch Tabelle 9 auf Seite 63),
werden alle weiterführenden Links aus den Dokumenten entfernt, um das NoFollow zu
simulieren. Zudem müssen die Navigationsframes entfernt werden, so daß das Frameset
nur noch aus dem Inhaltsframe besteht. Die in Abschnitt 5.3 beschriebene Methode, den
Spider über den NoFrame-Tag auf die Suchseite zu verweisen, wird dadurch jedoch
nicht tangiert. Im Gegensatz dazu funktioniert der ebenfalls in Abschnitt 5.3 implementierte Next-Link nicht zusammen mit Verity, da der Spider aufgrund der in Abschnitt
3.2.2 beschriebenen Probleme mit kategorisierten Ansichten so konfiguriert ist, daß
sämtliche URLs nach dem Begriff ?OpenView abgeschnitten werden. Daher wird die
Suchansicht ohne die entsprechenden Parameter aufgerufen, so daß alle darin enthaltenen Links angezeigt werden. Da die Anzahl der Links kleiner ist als die in der Serverkonfiguration eingestellte Maximalanzahl (vgl. Abschnitt 3.2.3), entstehen keine Probleme.
Um die Suchmaschine mit möglichst allen im Lösungskonzept abgedeckten Problembereichen zu konfrontieren, werden in der Datenbank eine Anzahl Dokumente und Seiten
von unterschiedlichem Typ und mit verschiedenem Inhalt benutzt. Diese sind im einzelnen:
-
Sechs normale Dokumente mit lexikonähnlichem Inhalt. Auf diese Weise soll die
korrekte Einordnung der Seiten durch den Indexer getestet werden.
-
Ein Dokument mit RichText-Inhalt, um zu beobachten, ob die Suchmaschine mit
dem von Domino generierten HTML-Code zurechtkommt.
-
Ein Dokument mit einer Sektion.
-
Ein Dokument, welches aus einer zusätzlichen Testdatenbank heraus referenziert
wird. Dazu wird eine weitere Datenbank auf Basis des Prototyps auf dem Server angelegt. Die referenzierte Webseite (Keyword-Test) sollte dementsprechend zweimal
im Index der Suchmaschine erscheinen, jedoch mit unterschiedlichen Schlüsselwörtern versehen.
25
Diese Abweichungen im Vergleich zu Webspidern soll in der nächsten Version von Verity behoben
werden.
-
74
Je ein Dokument und eine Seite mit unterschiedlichen Dateianhängen im PDFFormat (PDF = Portable Document Format). Da Verity auch PDF-Dateien durchsuchen kann, sollte auch diese Datei indiziert werden.
-
Eine Seite mit Pass Thru HTML und mit Dateianhang im HTML-Format.
-
Die Startseite bzw. den Inhaltsframe der Startseite.
-
Ein Dokument, für das der Meta-Tag Robots auf NoIndex gesetzt wurde. Dieses
Dokument sollte indiziert werden und somit auch nicht in den Trefferlisten auftauchen.
-
Ein Link auf eine HTML-Seite im entsprechenden Verzeichnis des Domino-Servers.
Dazu wird eine einfache HTML-Datei in das entsprechende Verzeichnis des Domino-Servers kopiert.
Die vom Spider bei jedem Durchlauf generierte Logdatei sowie eine Trefferliste, die aus
allen in diesem Test indizierten Webseiten besteht, stellen die Testergebnisse dar, die im
anschließenden Abschnitt analysiert werden.
5.5.2 Analyse der Testergebnisse
Nach Abschluß des Tests gilt es nun die Ergebnisse zu analysieren. Dabei wird kontrolliert, ob Verity die im vorangegangenen Abschnitt beschriebenen Dokumente und Seiten der Datenbank auch wie erwartet verarbeitet hat und wo eventuell Fehler aufgetreten
sind. Als Grundlage dazu dient zunächst die bereits erwähnte Logdatei. Wie in Abb. 24
zu sehen ist, zeichnet der Spider darin jede besuchte URL auf und protokolliert deren
weitere Verarbeitung (die gesamte Logdatei ist in Anhang 9.4.3 zu finden). Dieser Eintrag besteht im Normalfall aus einer Inserting-Anweisung, die URL wird an den Indexer
weitergegeben. Der in Abb. 24 gezeigte Fehler ist der einzige, der bei diesem Testlauf
aufgetreten ist. Es handelt sich hierbei um die URL, mit der die Sektion im entsprechenden Dokument expandiert wird. Aufgrund des darin enthaltenen Begriffes EXPAND
wird diese URL, wie im vorigen Abschnitt dargelegt, vom Verity-Spider ignoriert.
Verbose 11/24 11:39:35 (ind010003) Submission enqueued: <http://10.70.5.203/proofofc.nsf/search>.
Progress 11/24 11:39:35 (ind031000) Inserting <http://10.70.5.203/proofofc.nsf/search>.
Verbose 11/24 11:39:39 (ind010003) Submission enqueued:
<http://10.70.5.203/ProofofC.nsf/Search/BB385CE48592116CC12567E6005AA686?OpenDocument>.
Progress 11/24 11:39:39 (ind031000) Inserting
75
Verbose 11/24 11:39:43 (ind010004) Skipping key
<http://10.70.5.203/ProofofC.nsf/Search/ffec85358a6d65b6c12567ee004d6a2d?OpenDocument&Expand
Section=1> because of VdkVgwKey.
Abb. 24: Auszug aus der Logdatei des Verity-Spiders
Zählt man alle im vorigen Abschnitt aufgezählten Datenbankinhalte zusammen, erhält
man neunzehn Webseiten, von denen aufgrund des Robots-Tags jedoch nur achtzehn
indiziert werden sollten. Allerdings hat der Spider, wie der Logdatei in Anhang 9.4.3 zu
entnehmen ist, insgesamt zweiundzwanzig URLs abgearbeitet. Die fünf zusätzlichen
URLs lassen sich aber wie folgt erklären:
1. Die URL, die auf die zu expandierende Sektion verweist.
2. Da der Meta-Tag Robots bei Verity erst vom Indexer interpretiert wird (vgl. Verity-Konfiguration in Anhang 9.4.1), hat der Spider die nicht zu indizierende Seite
vorerst an den Indexer weitergegeben.
3. Aus demselben Grund wird auch die URL der Suchansicht selbst an den Indexer
weitergegeben.
4. Die Startseite wurde von dem Spider doppelt weitergegeben, da er sie über zwei
unterschiedliche URLs erreicht hat: Zum einen, wie erwartet, über den Link in der
Suchansicht und zum anderen direkt beim Einstieg in die Suche, da der Robots-Tag
fälschlicher Weise noch auf NoFollow gesetzt war (vgl. S. 73).
Bis auf die doppelte Erfassung der Startseite, welche auf einem trivialen Fehler bei der
Testvorbereitung beruht, läßt sich festhalten, daß der Spider sich wie geplant verhalten
hat. Im nächsten Schritt werden nun die im Index enthaltenen Seiten untersucht.
Wählt man als Suchanfrage den Datenbanknamen innerhalb der URL, erhält man eine
Trefferliste mit allen indizierten Webseiten. Abb. 25 auf nachfolgender Seite zeigt davon nur einen Ausschnitt, die komplette Liste ist in Anhang 9.4.2 enthalten. Wichtig
dabei sind vor allem die darin angezeigten Informationen: die URL und der Titel der
Webseite, die Beschreibung und die Schlüsselwörter, die aus den entsprechenden Mettags der Webseiten entnommen werden, sowie das Last-Modified Date. Anhand dieser Werte lassen sich folgende Erkenntnisse/Resultate ableiten:
76
Die Seite, für die der Meta-Tag Robots aud NoIndex gesetzt ist, wurde korrekterweise
nicht indiziert. Die Tatsache, daß trotzdem eine Webseite mehr als erwartet indiziert
wurde, beruht auf der oben bereits beschriebenen Doppelt-Erfassung der Startseite.
Die referenzierte Webseite wurde, wie im Konzept vorgesehen, zweimal indiziert, wobei jeweils unterschiedliche Schlüsselwörter aufgenommen wurden. Somit ist gezeigt,
daß mit der beschriebenen Trennung von Inhalt und Meta-Informationen die Erfassung
einer Seite in verschiedenem Kontext gewährleistet wird.
Auch das mit Hilfe des Meta-Tags HTTP-EQUIV auf den 29.09.1999 gesetzte LastModified Date wurde von dem Indexer richtig übernommen. Lediglich bei den Dateianhängen und der HTML-Datei, auf die diesbezüglich kein Einfluß genommen wird, weichen die Werte davon ab. Erfreulich dabei ist, daß der Domino-Server für diese Elemente das korrekte Datum ihrer Erstellung verwendet hat. Dafür hat der Domino-Server
bei der Seite mit Pass Thru HTML den von Hand gesetzten Wert - analog zu den Ausführungen in Abschnitt 3.2.1 - mit dem aktuellen Datum überschrieben. Entsprechend
wurde auch kein Last Modified Datum für die Seite übergeben, bei der dieses nicht
von Hand programmiert wurde.
Abb. 25: Auszug aus der Trefferliste von Verity
77
Das in diesem Kapitel entwickelte Lösungskonzept konnte also als korrekt bestätigt
werden. Dabei ist jedoch zu bedenken, daß aufgrund der teilweisen Inkompatibilität
von Verity nicht alle Aspekte in dem Proof of Concept berücksichtigt werden konnten.
Setzt man aber die vollständige Unterstützung der verwendeten Standards voraus, was
bei den anderen in dieser Arbeit betrachteten Suchmaschinen der Fall ist, sind auch die
Ansätze, die hier nicht verifizeirt werden konnten, als gesichert anzusehen.
Ausblick
78
6 Ausblick
Die bei der Durchführung des Proof of Concept aufgetretenen Problem haben ebenso
wie die vorgenommene Problemanalyse gezeigt, wie wichtig die Unterstützung der
Standards von Seiten der Suchmaschinen ist. Gerade in diesem Bereich ist aber in Zukunft davon auszugehen, daß die Suchmaschinen sich stetig weiterentwickeln und somit
immer mehr Standards unterstützen werden. Ein gutes Beispiel hierfür stellt die interne
Suchmaschine der Deutschen Bank AG dar, die, wie in Abschnitt 5.5.1 beschrieben, in
der nächsten Version unter anderem den Meta-Tag Robots vollständig verstehen wird.
Problematisch ist allerdings, daß im gleichen Maße, wie die Suchmaschinen weitere
Standards unterstützen, durch die intensive Forschung und Entwicklung im Bereich der
Internettechnologien immer wieder neue Standards geschaffen werden, so daß die
Suchmaschinenbetreiber diesbezüglich immer ein wenig dem Entwicklungsprozeß hinterherlaufen werden.
Neben neuen Problemen können innovative Technologien aber auch eine Chance für die
Unterstützung von Suchmaschinen darstellen. Ein solcher Ansatz wäre XML (Extended
Manipulation Language). Mit dieser Erweiterung des HTML-Standards wäre es möglich, die anzuzeigenden Informationen direkt aus den Notes-Elementen zu lesen (vgl.
Lotus Development Corporation 1999a) und über einen normalen Webserver wie z. B.
Apache zu publizieren. Mit dieser Vorgehensweise könnten somit die in Kapitel 3 beschriebenen Probleme umgangen werden, die direkt mit dem Domino-Server zusammenhängen.
Des weiteren wäre es sinnvoll, die bestehenden Standards für Suchmaschinen zu erweitern. Gerade im Bereich der Sicherheit reichen die beiden in Abschnitt 4.3 beschriebenen Methoden nicht aus, da sie zu unflexibel sind. Wünschenswert wäre z. B., über eine
Erweiterung des HTML-Standards zu erreichen, daß für jeden Link einzeln angegeben
werden kann, ob der Spider diesen verfolgen soll oder nicht.
Auch aus der Sicht des Informationssuchenden sind in der Zukunft einige neue Entwicklungen zu erwarten. Vor allem bei dem Suchinterface ist ein Trend hin zu sogenannten Portalen zu beobachten. Wie der Name schon andeutet, sollen Portale den Einstieg zu den gewünschten Informationen gewährleisten. Daher bieten sie über die Suche
im Internet hinaus jedem Benutzer die Möglichkeit, seine eigene Informationsübersicht
zusammenzustellen. Dabei kann er sich aus beliebigen Bereichen die jeweils aktuellen
Ausblick
79
Informationen zusammentragen lassen, z. B. die aktuellen Börsenkurse, Wetterinformationen oder die neuesten Sportergebnisse. Die Betreiber solcher Portale wollen auf diese
Weise erreichen, daß ihre Portal von den Benutzern als Einstiegsseite zum WWW genutzt werden. Dieses Prinzip läßt sich auch auf das Intranet im untersuchten Unternehmen übertragen, um so jedem Mitarbeiter die für ihn wichtigen Informationen schnell
bereitzustellen.
Zusammenfassung
80
7 Zusammenfassung
In der vorliegenden Arbeit wird ein Konzept zur Integration von Suchmaschinen in die
Corporate Knowledge Management Plattform NetFicient der Deutschen Bank AG entwickelt. Der Schwerpunkt liegt dabei auf der Erfassung der mit NetFicient publizierten
Webseiten durch den Spider und deren korrekte Einordnung in den Index der Suchmaschinen. Dazu werden zunächst die Vorgehensweise und Architektur von Suchmaschinen detailliert dargestellt und die damit zusammenhängenden Technologien beschrieben
sowie die im Kontext dieser Arbeit relevanten Begriffe definiert, um so eine terminologische Basis zu schaffen.
Im zweiten Schritt wird die gegebene Problematik einer umfassenden Analyse unterzogen. Für die dabei beobachteten Schwierigkeiten konnten vor allem zwei Hauptursachen
identifiziert werden: Zum einen unterstützen nicht alle Suchmaschinen die im WWW
üblichen Standards und Technologien. Speziell Framesets und Java stellen die Suchmaschinen dabei vor große Probleme. Zum anderen unterscheidet sich der Domino-Server
trotz seiner erweiterten Webintegration von „normalen“ Webservern wie z. B. Apache.
Gerade bei der Webdarstellung von dynamischen Notes-Elementen wie Ansichten oder
Gliederungen sind Inkompatibilitäten mit Suchmaschinen zu beobachten. Die Ergebnisse dieser Problemanalyse stellen den Ausgangspunkt für die zu entwickelnden Lösungsansätze dar, sollen aber auch die Entwickler von NetFicient für die Problematik sensibilisieren.
Als nächstes werden Lösungsansätze für die analysierten Probleme evaluiert. Dabei
werden Vor- und Nachteile von Standardlösungen diskutiert und ihre Eignung für NetFicient bewertet. Darüber hinaus werden diese weiterentwickelt und auch neue Konzepte zur Lösung der Probleme erarbeitet, um die von NetFicient gegebenen speziellen
Anforderungen erfüllen zu können. Zudem wird auf existierende Zielkonflikte und nicht
oder nur mit unverhältnismäßigem Aufwand zu lösende Bereiche hingewiesen. Zusätzlich wird in der Form von Anforderungen ein Konzept für ein leistungsfähiges Suchinterface dargelegt, um auch die Sicht des Informationssuchenden zu verdeutlichen, der
im Rahmen des von NetFicient angezielten Knowledge Managements eine wichtige
Rolle spielt.
Auf Basis dieser Ergebnisse wird dann anhand eines Prototyps ein umfassendes Konzept zur Unterstützung von Suchmaschinen in NetFicient entwickelt. Die grundlegende
Zusammenfassung
81
Idee dabei ist, den Weg des Spiders mit Hilfe von speziell konzipierten Suchseiten so zu
kontrollieren, daß er alle Webseiten in einer für ihn verarbeitbaren Form erfassen kann.
Zudem werden zur besseren Einordnung und zur Erzielung eines besseren Rankings der
Webseiten die entsprechenden Meta-Informationen im HTTP-Header und HTML-Head
dahingehend manipuliert. Die Unterstützung der von NetFicient geforderten Multiframefunktionalität kann aus dargelegten Gründen jedoch nicht im vollen Umfang gewährleistet werden. Zur Verifikation der konzipierten Lösung wird der entwickelte
Prototyp einem abschließenden Test mit der internen Suchmaschine der Deutschen
Bank AG unterzogen, in dem sich die Richtigkeit des Konzeptes bestätigte.
Als Resümee bleibt zu sagen, daß mit Hilfe des hier entwickelten Konzeptes ein Großteil der gegebenen Probleme gelöst oder umgangen werden kann. Für nicht zu lösende
Bereiche werden die Gründe und Schwierigkeiten ausführlich diskutiert und in einem
Ausblick Entwicklungen und Standards vorgestellt, die eine Lösung dieser Probleme in
Aussicht stellen.
Literaturverzeichnis
8 Literaturverzeichnis
Altavista 1999:
Altavista: Advanced Search Help, http://www.altavista.com, 1999.
Axt/Hertel/Wagner 1999:
Axt, Heilo; Hertel, Matthias; Wagner, Martin: Lotus Domino & Notes 5 Kompendium, Markt&Technik, München, 1999.
Berners-Lee 1994:
Berners-Lee, Tim: Universal Resource Identifiers in WWW: A Unifying Syntax for
the Expression of Names an Adresses of Objects on the Network as used in the
World Wide Web, RFC-1630, CERN, Schweiz, 1994.
Berners-Lee et al. 1994:
Berners, Lee, Tim; Masinter Larry; McCahill, Mark: Uniform Resource Locators
(URL), RFC-1738, CERN, Xerox Corporation, University of Minnesota, Mineapolis,
1994.
Borggraefe 1999:
Borggraefe, Stefan: Reiche Ernte - Hierarchische Suchindizes mit Harvest. In iX
3/1999, S. 126ff.
Burch 1999:
Burch, Barbara: Domino R5 Technical Overview, http://www.notes.net/today.nsf, Irsi Today, Iris Associates, April 1999.
Casselberry 1997:
Casselberry, Rick: Das perfekte Intranet: Die richtige Plattform auswählen; firmeninterne Web-Seiten gestalten; mit HTML-Editoren arbeiten, Markt&Technik, München, 1997.
Collins et al. 1999:
Collins, Fiona; Morrison, David; Nielsen S. P.; Serpola, Samir; Strobl, Reinhold:
Lotus Domino Release 5: A Developer’s Handbook, First Edition, IBM Corporation
International Technical Support Organisation (ITSO), Cambridge, Massachusetts,
USA, 1999.
Comer 1988:
Comer, Douglas: Internetworking with TCP/IP: Principles, Protocols an Architecture, Prentice Hall, Englewood Cliffs, New Jersey, 1988.
Daibenzeiher et al. 1997:
Daibenzeiher, T.; Koch, O.; Kowalski, T.: Lotus Notes & Domino 4.6: Der Einstieg
ins Information Networking, C&L Computer und Literaturverlag, Vaterstetten, 1997.
Dennig et al. 1997:
Dennig, Jens; Gutperlet, Klaus; Rosenow, Eike G.: Lotus Domino & Notes 4.5,
Markt&Technik, München, 1997.
Deutsche Bank AG 1999:
Deutsche Bank AG, Transaction Services, Methods and Procedures, db-search –
Webmaster Guide, Internal Paper, Frankfurt am Main, 1999.
Deutsche Bank AG 1999a:
Easynet: Netficient Teamroom Database, Anforderungen R2, 1999.
82
Deutsche Bank AG 1999b:
GCC Bank Dokumentation: NetFicient – Ausblick für das Jahr 2000, White Paper,
1999.
Deutsches Institut für Normung 1996:
Deutsches Institut für Normung: DIN EN 29241: Ergonomische Anforderungen für
Bürotätigkeiten mit Bildschirmgeräten-Teil10: Grundsätze der Dialoggestaltung,
Entwurf, Beuth Verlag, Berlin, 1996.
Dierker/Sander 1998:
Dierker, Markus; Sander, Martin: Lotus Nores 4.6 und Domino: Integration von
Groupware und Internet, Addison-Wesley, Bonn u. a., 1998.
Fielding et al. 1997:
Fielding, et al.: Hypertext Transfer Protocol – HTTP/1.1, RFC-2068, MIT, 1997.
Fielding et al. 1999:
Fielding et al.: Hypertext Transfer Protocol – HTTP/1.1, RFC-2616, MIT, 1997.
Florio 1999:
Florio, Susan: Domino R5 Domain Search, http://www.note.net/today.nsf , Iris Today, Iris Associates, März 1999.
Florio 1999a:
Florio, Susan: The History of Notes and Domino, http://www.notes.net/history.nsf,
Iris Today, Iris Associates, April 1999.
Hajji 1998:
Hajji, Farid: Perl: Einführung, Anwendungen, Referenz, Addison Wesley, Bonn,
1998.
Knut/Bager 1997:
Knut, Detlef; Bager, Joe: Datenfischer – Metasuchwerkzeuge erleichtern die Recherche im Web. In c't 2/1997, S.170-175.
Keil-Slawik 1996:
Keil-Slawik, Reinhard: Von der Feuertafel zum Kampfroboter – Die Entwicklungsgeschichte des Computers, Paderborn 1996.
Keil-Slawik 1997:
Keil-Slawik, Reinhard: Grundlagen der Systemgestaltung, Vorlesungsunterlagen,
Paderborn, 1997.
Lawrence/Giles 1998:
Lawrence, Steve; Giles, C. Lee: Searching the World Wide Web. In Science, Vol.
280 (1998), S. 98-100.
Lotus Development Corporation 1998:
Lotus Development Corporation: Domino Extended Search, White Paper, Cambridge, Massachusetts, 1998.
Lotus Development Corporation 1999:
Lotus Development Corporation: Domino Designer 5 Help, Datenbank, Cambridge,
Massachusetts, 1999.
Lotus Development Corporation 1999a:
Lotus Development Corporation: The Domino Application Server – Platform for
XML, White Paper, Cambridge, Massachusetts, 1999.
83
Lotus Development Corporation 1999b:
Lotus Development Corporation:Lotus Domino Designer R5 – The Power to Build
Secur Web Applications that Extend the Enterprise – Appilcation Development with
Domino Designer, Documentation, Cambridge, Massachusetts, 1999.
Luckhardt 1998:
Luckhardt, Norbert: Vielspurig - Was die Reise auf der Datenautobahn bringt. In c't
2/1998, S.86-89.
Mann, 1999:
Mann, Raimund: Domino Designer R5, Anwendungsentwicklung mit Lotus Notes,
C&L Computer und Literaturverlag, Vaterstetten, 1999.
Maurer 1996:
Maurer, Rainer: HTML und CGI-Programmierung: Dynamische WWW-Seiten erstellen, dpunkt, Heidelberg, 1996.
Münz/Nefzger 1998:
Münz, Stefan; Nefzger, Wolfgang: HTML 4.0 Handbuch, Professional Series, Franzis‘ Verlag, Poing, 1998.
Nastansky 1993:
Nastansky, Ludwig: Nach 20 Jahren CSCW-Forschung: Durchbruch in der Praxis bei
Groupware-Anwendungen in Client-Server Architekturen. In Nastansky, Ludwig:
Workgroup Computing, S+W Steuer und Wirtschaftsverlag, Hamburg, 1993, S. 120.
Nastansky et al. 1994:
Nastansky, L.; Fischer, J.; Herold, W.; Dangelmeier, W.; Wolff, R.: Bausteine der
Wirtschaftsinformatik: Grundlagen, Anwendungen, PC-Praxis, S+W Steuer- und
Wirtschaftsverlag, Hamburg 1994.
Ott/Nastansky 1997:
Ott, Markus; Nastansky, Ludwig: Kommunikationsmanagement zwischen Teams –
Paperless Office am Beispiel GroupOffice. In: Kommunikationsmanagement in verteilten Unternehmen – Fünf Jahre Wirtschaftsinformatik an der Universität-GH Paderborn, Dangelmaier, W.; Fischer J.; Herold, W.; Nastansky,L.; Suhl, L.; Wolff, R.
(Hrsg.), VDI Verlag, Reihe 10, Nr. 478, 1997, S. 21-44.
Ramm 1998:
Ramm, Frederik: Recherchieren und Publizieren im World Wide Web, 2. Auflage,
Friedr. Vieweg & Sohn Verlagsgesellschaft mbH, Braunschweig/Wiesbaden 1996.
Sander-Beuermann 1996:
Sander-Beuermann, Wolfgang: Meta-Ebene – Mehrere Suchmaschinen gleichzeitig
abfragen. In iX 9/1996, S. 146ff.
Sander-Beuermann 1998:
Sander-Beuermann, Wolfgang: Schatzsucher - Die Internet-Suchmaschinen der Zukunft. In c't 13/1998, S. 178-184.
Smolnik 1999:
Smolnik, Stefan: Strategische Nutzung von Groupware- und I*Net-Technologien im
IT-Umfeld einer internationalen Großbank - Vergleich von Technologien, Dokumentation und Erstellung eines Best Practice Guide zur I*Net-Programmierung, Diplomarbeit, Paderborn, 1999.
84
Sonnenreich/Macinta 1998:
Sonnenreich, Wes; Macinta, Tim: Web Developer.com – Guide to Search Engines,
Wiley Computer Publishing, New York usw. 1998.
Sullivan 1999:
Sullivan, Danny: Search Engine Watch – The Major Search Engines,
http://www.searchenginewatch.com/facts/major.html, März 1999.
Sullivan 1999a:
Sullivan, Danny: Search Engine Watch – How Search Engines work,
http://www.searchenginewatch.com/webmasters/work.html, März 1999.
Sullivan 1999b:
Sullivan, Danny: Search Engine Watch – Search Engine Design Tips,
http://www.searchenginewatch.com/webmasters/tips.html, März 1999.
Sullivan 1999c:
Sullivan, Danny: Search Engine Watch – Search Engine Features Chart,
http://www.searchenginewatch.com/webmasters/features.html, März 1999.
Tanenbaum 1989:
Tanenbaum, Andrew S.: Computer Networks, Second Edition, Prentice Hall, Englewood Cliffs, New Jersey, 1989.
Wong 1997:
Wong, Clinton: Web Client Programming with Perl, O’Reilly & Associates, Inc.,
1997.
85
Anhang
86
9 Anhang
9.1 Zusätzliche Informationen zum Thema Suchmaschinen
9.1.1 Liste der Suchmaschinen im WWW
Die folgenden Liste gibt einen Überblick der im World Wide Web zur Verfügung stehenden Suchmaschinen. Dabei wird kein Anspruch auf Vollständigkeit erhoben, sondern es soll vielmehr die Vielzahl und Vielfältigkeit der existierenden Suchmaschinen
verdeutlicht werden.
Quelle:
http://dir.yahoo.com/Computers_and_Internet/Internet/World_Wide_Web/Searching_th
e_Web/Search_Engines/
•
Aesir Custom Search - Customize your favorite search engine with output filters.
•
Ahoy! - The Homepage Finder
•
Airport Search Engine - ASE database contains airport- codes and a list of links
to airport pages on the web.
•
ALIWEB - Australia mirror of the ALIWEB database at Nexor.
•
Alku - provides links to Finnish web-sites as well as a brief glossary and guide
on the internet. In Finnish.
•
AltaVista - web and newsgroup search engine.
•
AltaVista Australia - mirror site providing Australian, New Zealand, and Pacific
Rim users with faster access.
•
AltaVista Canada
•
Ananzi - search engine dedicated to the South African domain.
•
Anzwers
•
Aqueous - dedicated to sites that have water related content.
Anhang
87
•
Area 52 - Macintosh, Amiga, OS/2 searchs a specialty.
•
Arkansas Direct - search engine serving the state.
•
Astalavista - daily updated search engine monitoring hundreds sites with hack &
crack stuff.
•
AusIndex
•
Aviation Search Engine from Totavia
•
BabyOIL - resource discovery system - Simple interface to some of the most
popular Internet resources: WWW, Libraries, Software, People, Tech Report,
Online documents
•
Bigstuff
•
Biochemistry Easy Search Tool (BEST) - indexes educational sites with biological content useful to biochemists and other researchers in the life sciences.
•
BizAds Business Locator - search engine dedicated to business listings. Come
add your business for increased visibility or use our lightening fast business locator.
•
Business Seek
•
Cinemachine - brought to you by Addicted to Noise.
•
Claymont.com - C
•
Clever Project - publications and ongoing work at IBM Almaden Research
Center to develop algorithms and systems for solving the problem of information overload.
•
Community-based Navigation - We are testing an enhanced version of Mosaic
that supports fast Likert scale rating and automatically pools item-ratings in a
community server that can recommend and evaluate URLs.
•
Company Site Locator - The tool for searching for companies' websites when
you don't know the exact URL address.
•
CompuServe@
•
Crafts Search - search engine dedicated to crafts.
Anhang
•
88
CurryGuide - meta search engine allowing searches within the UK, Europe, and
worldwide.
•
Direct Hit - ranks search results according to what other people have selected as
the most relevant and popular sites for your search request.
•
Discovery Channel Online Search Engine
•
DIY Search - search engine dedicated to the DIY music, e-zine and arts community.
•
EC Search - specializing in electronic commerce.
•
EgoSurf - search tool finds web pages that include your name, or any name you
provide.
•
El Faro - buscador robótico o "araña" que recorre el web en busca de contenido
en el idioma castellano y lo agrega a una base de datos, dentro de la cual el usuario puede realizar búsquedas.
•
Electric Monk - allows users to perform natural language web searches in plain
English.
•
EuroFerret - index of European web sites provided by Muscat Ltd.
•
Euroseek
•
excite - is a global media Co. offering consumers and advertisers comprehensive
Internet navigation services with extensive personalization capabilities. Excite,
Inc.'s services include the Excite and WebCrawler brands.
•
Fast Search
•
Fido the Shopping Doggie
•
Fiji Search Engine
•
Filez - search page with an index of over 60 million files and all the popular
corporate and shareware sites.
•
Fish4It - from Urban Desires; limits results to just one "damn near perfect"
URL. Discover the other fish in cyberspace.
•
G-Spot - Philipine search engine.
Anhang
89
•
GeoIndex - search tool for geo-environmental professionals.
•
Global Online Directory - search engine with unique search facilities and free
classified ads.
•
Globe Page - Asia search service in English, Chinese GB, and Big 5 encoding.
•
Google! - uses text-matching techniques to find pages that are both important
and relevant to your search.
•
GoTo.com@
•
Heuréka - search engine for the Hungarian Webspace.
•
HotBot
•
iAtlas - focus searches by industry categories, geographic location, site popularity, and other specialty filters.
•
Ibeau - search and navigational directory of sites featuring Asian celebrities.
•
ICQ iT!
•
In 2 Ireland - search resource with meta search and a multi submit engine.
•
Inference Find - the intelligent massively fast parallel web search.
•
Infohiway - Point-n-go access to the Infohiway. GeoSurfer reveals the web geographically, Plus... FTP, Gopherspace and more.
•
InfoJump - article search engine that indexes electronic periodicals and online
versions of print publications.
•
Informant Server, The - personal search agent; will send email when your favorite urls are updated.
•
InfoTiger Search Engine - Intelligent search - COOL ranking!
•
InfoZona - state-specific searchable database of links.
•
Irena - Web Connections Finder - glean from a target page of this Web server all
relevant hypertext links and their annotations. Irena is is especially useful for locating links to resources referenced in long, complex and densly written HTML
documents.
•
Italian Spider
Anhang
90
•
James Kirk Search Engine - looks specifically for Star Trek sites.
•
keyword.com
•
Law Enforcement Links Directory & Police Search Engine and Directory - categories include operational support, crime statistics, information resources, and
administrative support.
•
LinkMaster
•
Links2Go - surf the web sideways.
•
Lokace - francophone search engine.
•
LuXPoint - internet directory and search for Luxembourg.
•
Lycos - develops and provides online guides to locate and filter information on
the Internet. Products enable users to accurately identify and select information
of interest to them.
•
Magic the Gathering Search Engine - find the cards that would go well in your
deck.
•
MasterSite
•
MathSearch - search a collection of mathematical Web material
•
Matilda - waltz the web.
•
Maxisearch - with local, national and international news.
•
Mister Driver - search engine for device drivers.
•
Mojoe
•
Money$earch - geared towards small business owners and on-line investors in
the financial markets. All sites are reviewed and described on-line.
•
MOSHIx2 - Japanese and English search engine. Also has a browseable directory of sites.
•
MRO-Explorer - industrial search engine to locate distributors, manufacturers,
and related subjects.
•
MSN Internet Search
Anhang
91
•
Mug-O-Milk - search by asking a question or entering keywords.
•
MusicSearch - music search engine with over 5,000 links and growing.
•
NationalDirectory
•
Netscape Search - combines results from the Netcenter, Open Directory, and the
Web.
•
Netword - a word or short phrase that provides free access to an Internet destination. People & companies are creating Networds so you can find their information easily.
•
News Hunt - links to free newspaper archives and a searchable database of searchable newspapers.
•
Nordic Web Index - free web searching particular to the Nordic countries. The
NWI has Danish, Icelandic, Finnish, Norwegian, and Swedish service points.
•
Northern Light@
•
Oingo - offering a meaning-based search service.
•
OneKey
•
Open Text Web Index
•
PhilanthropySearch.com - serves the non-profit and philanthropic sector.
•
PlanetClick - searchable and browseable directory of websites prioritized by user
ratings and reviews.
•
PlanetSearch
•
Poke! - search assistant that uses javascript and frames. It is always with you, an
alt + tab away.
•
Pollinia: Network Orchid Stuff - search engine that focuses on orchid-related
web sites.
•
Pregnancy and Parenting Search Engine - a search engine devoted to pregnancy
and parenting related web sites. Categories include a range of topics relating to
pregnancy, parenting, and family issues.
Anhang
•
92
Public Safety Search Engine - features various public safety only web sites in
several fields like; law enforcement, fire, ems and health.
•
QuestFinder - offers a list of categories.
•
Radar - international search engine. In English and Spanish.
•
Scour.Net - guide to multimedia on the Internet. Use it to find audio, video,
images and animation.
•
Scrub The Web
•
Search Argos - search for web sites and documents that cover the ancient world.
•
Search By Media - search the Web for sites, audio, images, and video.
•
Search King - engine that relies on web surfing for quality searching results. Searchers vote on sites, assuring relevant internet results.
•
Search NZ
•
Search.bg - search engine dedicated to Bulgarian companies and internet resources.
•
Search.NL - Search Dutch cyberspace. Unique fuzzy searching eliminates the
need for correct spelling of search queries.
•
Searching Satanism - looks specifically for satanic listings.
•
SearchMil.com - search engine indexing the .mil domain.
•
Searchopolis
•
Searchport - promotes websites by linking.
•
SemioMap - discovery search tool that uncovers relationships among Internet
and Intranet documents.
•
Sesna - Ukrainian Search - search engine for Ukrainian sites.
•
Simmany - Korean search engine.
•
SimpleSearch.com - search engine targeted for the novice computer user. Features easy to read results.
•
Sitexplorer - in English, German, Italian, and Spanish.
Anhang
•
93
Snoopie - Over 5 million files have been indexed for download at over 450 ftp
sites World Wide. A search can be completed as fast as 10 milliseconds.
•
Sourcebank - specializes in sites for software developers.
•
Spider's Apprentice, The
- a public
service site that offers help on searching the Web. We also analyze and rate the
major search engines.
•
Sportsdogs.com - sports oriented search engine.
•
StreamSearch.com - specialized global search engine for audio and video on the
web.
•
Super Snooper - for kids and adults who prefer not to be presented with obscenity, hatred, drug-promotion or bigotry on the internet.
•
Surfer's Edge - searchable and browsable index of Singapore and Singapore related web sites.
•
TechnoFind - search facility for Singaporean Web sites.
•
TheLinks - includes major search engines, plus 800 numbers, zip codes, usp,
yellow pages and medical databases.
•
Thunderstone - an index of sites, not pages.
•
Travel-Finder Spider - demonstration contains information collected on travel
related resources and information.
•
Ugabula - buscador: search Spanish and Latin sites.
Anhang
94
•
UKMax
•
United States of America Web Resource
•
WebDirect! - add, modify or delete websites and/or Yellow Page indexes, keywords, and display search results the way you want to.
•
Webindex - internet search engine for Greece.
•
Websurfer
•
WebTop.com - uses probability theory to rank keywords and suggest additional
related terms.
•
WestMichigan.com - local search engine.
•
What-U-Seek
•
whoizzy
•
World Access Internet Navigator
•
Worldwide Embassies and Consulates Search Engine - searchable database for
addresses, telephone numbers, emails, and websites of world embassies and consulates.
•
WWWomen Search Directory - comprehensive search engine. Includes resources for arts, business, computers, internet, education, feminism, health, lesbians,
magazines, shopping, fashion, sports, and more.
•
Yam Web Navigator@
•
Yep - surf engine based on quality and popularity.
•
Zebra - search South Africa.
•
ZenSearch
Copyright © 2000 Yahoo! Inc. All Rights Reserved. - Company Information
Anhang
95
9.1.2 Spider Spotting Chart
In der folgenden Tabelle werden für die in dieser Arbeit betrachteten Suchmaschinen
jeweils der Hostname sowie die Agentennamen, unter dem die Spider sich gegenüber
den Webservern identifizieren, aufgelistet. Mit Hilfe dieser Informationen ist es den
Betreibern von Websites möglich, den anfragenden Webclient als Suchmaschine zu
erkennen und so eventuell spezielle Seiten an den Spider zurückzugeben (vgl. Abschnitt
4.1.5).
Suchmaschine
Agent Names
Host Names
AltaVista
Scooter/2.0 G.R.A.B. X2.0
scooter.pa-x.dec.com
(normal)
Scooter/1.0 scooter@pa.dec.com
scooter*.av.pa-x.dec.com
AltaVista
Scooter/1.0
add-url.altavista.digital.com
(instant)
ww2.altavista.digital.com
Euroseek
Arachnoidea
*.euroseek.com
Excite
ArchitextSpider
crawl*.atext.com
ArchtextSpider
crimpshrine.atext.com
BackRub/2.1
*.stanford.edu
(mega spider)
Excite
(fresh spider)
Google
backrub@google.stanford.edu
http://google.stanford.edu
Inktomi
Slurp/2.0 (slurp@inktomi.com)
(u.a. hotbot)
http://www.inktomi.com/slurp.html
Infoseek
InfoSeek Sidewinder/0.9
(normal)
Infoseek
(instant)
*inktomi.com
*.infoseek.com
204.162.98.90
Mozilla/3.01 (Win95;I)
*.infoseek.com
204.162.98.90
Anhang
Suchmaschine
Lycos
96
Agent Names
Lycos_Spider_(T-Rex)
(regular)
Lycos
Host Names
lycosidae.lycos.com
*.pgh.lycos.com
Lycos_Spider_(T-Rex)
*.sjc.lycos.com
Northern Light
Gulliver/1.2
taz.northernlight.com
WebCrawler
siehe Excite
siehe Excite
(Add URL spider)
Tabelle 10: Spider Spotting Chart
Anhang
97
9.2 HTTP-Header Informationen des Domino-Servers
In Abschnitt 3.2.1 wird im Rahmen der Problemanalyse untersucht, welche Werte für
die beiden HTTP-Header Last-Modified und Expires von dem Domino-Server in
Abhängigkeit von den verschiedenen Notes-Elementen und deren Webdarstellung zurückgegeben werden. Dabei wird eine einfache Notes-Datenbank, die alle zu suchenden
Elemente enthält, auf einen Domino-Server für den Webzugriff zur Verfügung gestellt.
Auf diese Weise können mit dem Netzwerkutility NetCat die einzelnen Notes-Elemente
vom Domino-Server angefordert und die zurückgegebenen HTTP-Header des DominoServers untersucht werden. Die Ergebnisse dieses Tests werden in Tabelle 3 auf Seite
40 zusammengefaßt. An dieser Stelle werden nun die HTTP-Header aufgeführt, auf
deren Basis die Ergebnisse für die Problemanalyse ermittelt werden.
Notes-Element
Vom Domino-Server zurückgelieferter HTTP-Header
(Darstellung)
HTTP/1.1 200 OK
(normal)
Date: Thu, 07 Oct 1999 12:05:01 GMT
Connection: close
Content-Length: 554
HTTP/1.1 200 OK
Seite
(Pass Thru HTML) Date: Thu, 07 Oct 1999 12:04:16 GMT
Connection: close
Content-Length: 462
HTTP/1.1 200 OK
Dokument
(normal)
Date: Thu, 07 Oct 1999 12:46:32 GMT
Connection: close
Content-Length: 619
HTTP/1.1 200 OK
Dokument
Connection: close
Content-Length: 559
HTTP/1.1 200 OK
Ansicht
(normal)
Date: Thu, 07 Oct 1999 12:09:01 GMT
Seite
Anhang
98
Connection: close
Content-Length: 3099
Notes-Element
Vom Domino-Server zurückgelieferter HTTP-Header
(Darstellung)
HTTP/1.1 200 OK
Connection: close
Ansicht
Ansicht
(Applet)
HTTP/1.1 200 OK
Date: Thu, 07 Oct 1999 12:05:49 GMT
Connection: close
Tabelle 11: Liste der HTTP-Header in Abhängigkeit der Notes-Elemente
Anhang
99
9.3 Dokumentation des entwickelten Prototyps
Die hier vorliegende Dokumentation bezieht sich auf den im Kapitel 5 entwickelten
Prototyp. Die für den Proof of Concept durchgeführten Änderungen werden hier nicht
berücksichtigt, da in Abschnitt 5.5.1 bereits ausführlich darauf eingegangen wurde.
Mit Hilfe von Seiten wird ein Frameset generiert, daß der in Abschnitt 3.1.2 gegebenen
Definition entspricht. Dazu wird eine Seite („Start“) mit Pass Thru HTML benutzt, in
der das Frameset generiert wird. Zusätzlich wird im HTML-Bereich NoFrame der Link
auf die Suchseite eingefügt. Damit der Spider diesen verfolgen kann, wird der Meta-Tag
Robots für diese Seite lediglich auf NoIndex gesetzt. Da für die Seiten in den jeweiligen
Frames („NavFrame“, „TopFrame“, „Startseite“) dieser Tag auf None gesetzt ist, stellt
der Link auf die Suchseite den einzigen Weg für den Spider dar. Um zumindest eine
einfache Navigation zu ermöglichen, wurde in die Seite für den Navigationsframe eine
Ansicht mit Links auf alle Dokumenten („Nav“) eingebettet, während die Seite für den
Topframe die Image Map der aktuellen PowerPublishing-Version von NetFicient enthält.
Zur Konfiguration der Datenbank wird ein Dokument auf Basis der Maske „Setup“ generiert. Hier werden die spezifischen Meta-Informationen der Datenbank gespeichert.
Dazu werden in den entsprechenden Feldern die Schlüsselwörter sowie die Links auf
die jeweiligen Navigationsframes eingetragen.
Zum Erstellen von Webseiten dient die Maske „New“. Neben einigen Standardfeldern
wie Titel, Autor, Datum und Body enthält diese Maske weitere Felder, die zur Eingabe
von suchmaschinen-relevanten Informationen dienen:
-
Description
Kurze Beschreibung des Seiteninhalts zur Generierung der MetaTags Description und Summary. Dieses Feld ist als Mußfeld deklariert. Zudem wird der eingegebene Text automatisch auf die für
Suchmaschinen gebräuchlichen 255 Zeichen reduziert.
-
Keywords
Dropdown-Feld zur Eingabe der Schlüsselwörter, die im Meta-Tag
Keywords gesetzt werden. Die zur Auswahl stehenden Schlüssel-
wörter werden dabei über die @DbColumn-Anweisung erstellt, um
Konformität bezüglich der verwendeten Schlüsselwörter zu gewährleisten.
Anhang
-
Relevanz
100
Über dieses Feld wird die Information für den internen Meta-Tag
Relevance abgefragt. Der Benutzer kann dabei aus den vorgegebenen
Werten niedrig, mittel, hoch und sehr hoch wählen.
-
Index
Mit Hilfe dieser Checkbox kann der Benutzer angeben, ob diese Seite
indiziert werden soll. Dazu wird der Meta-Tag Robots gemäß diesem
Feldwert gesetzt.
In der Maskeneigenschaft HTML Head Content werden dann mittels der Feldwerte folgende Meta-Tags generiert: Robots, Description, Summary, Relevance,
Last_Modified, Author.
Wird eine Webseite aus einer anderen Datenbank referenziert, wird in der Datenbank,
die die Webseite enthält, ein spezielles Dokument („reference“) angelegt, in dem der
Name der referenzierenden Datenbank sowie die Notes-DocID in den entsprechenden
Feldern gespeichert wird. Um eine solche Referenzierung vorzunehmen, wird ein neues
Link-Dokument erzeugt, welches die entsprechende URL enthält.
Zu den drei beschriebenen Dokumententypen enthält die Datenbank die entsprechenden
Ansichten, die zum Zugriff auf die Dokumente, Referenzen und Links im Notes-Client
gedacht sind. Da sie darüber hinaus keine besonderen Funktionen aufweisen, müssen sie
an dieser Stelle auch nicht weiter erläutert werden.
Die für die Suchmaschinen bestimmte Suchansicht („search“) enthält entsprechend alle
Dokumente, die auf den Masken „New“, „reference“ und „link“ basieren. In der einzigen Spalte der Ansicht werden HTML-Links auf die Dokumente generiert. Für die Referenzdokumente wird zusätzlich der Name der refernzierenden Datenbank als Parameter übergeben. Um Probleme mit Suchmaschinen zu vermeiden, wird Ansicht auf Pass
Thru HTML gesetzt. Zusätzlich wird die Ansicht in eine Schablone eingebettet, die den
in Abschnitt 5.3 beschriebenen Next-Link enthält.
Zur Anzeige der Webseiten für die Suchmaschinen wird nicht die Maske „New“, sondern eine spezielle Maske („4search“) über die Form Formula Eigenschaft der Suchansicht benutzt. Diese Maske ist im Prinzip genauso aufgebaut wie die Maske „New“,
enthält aber einige zusätzliche Funktionen, die ausführlich in Kapitel 5 beschrieben
werden.
Anhang
101
9.4 Protokollierung des Proof of Concepts
9.4.1 Protokoll vom 30.09.1999
Datum:
30. September 1999, 10.00-16.00
Anwesende der Deutschen Bank AG: Arne Priewe, Jochen Kehr
Nach der Installation der Notes-Datenbanken und HTML-Dateien auf dem DominoServer wurde durch Herrn Kehr die Konfiguration des Verity-Spiders vorgenommen.
(siehe Abb. 26).
Abb. 26: Konfiguration der Verity-Suchmaschine
Für den Proof of Concept sind dabei folgende Einträge interessant:
-
Start-URL: Adresse für den Startpunkt des Spiders. In diesem Falle die IP-Adresse
des Domino-Servers (10.70.5.203) und der Name der Testdatenbank (proofofc.nsf).
-
Pretty Name of the Web-Server: Bezeichnung zur Identifikation des Servers in Verity.
Anhang
-
102
Web Server Software: Mehrere Auswahlmöglichkeiten wie z. B. Domino, Apache
etc., die wichtig für einige automatische Einstellungen von Verity sind. Wird hier
ein "normaler" Webserver gewählt, nimmt Verity zunächst eine Vollindizierung aller Seiten des Webservers vor. Bei späteren Durchläufen werden lediglich veränderte Seiten vom Spider weitergegeben. Im Falle eines Domino-Servers wird bei jedem Durchlauf ein neuer Index erzeugt. Für diesen Test wurde Verity nachträglich
allerdings so konfiguriert, daß lediglich ein Update vorgenommen wird, um das
Last-Modified Datum im HTTP-Header zu testen.
Erster Spiderdurchlauf:
Wie schon am Durchlauf der Logdatei ersichtlich ist, die bei jedem Spiderdurchlauf
erzeugt wird, brach der Spider aus der Datenbank aus und begann sämtliche Datenbanken im Root-Verzeichnis des Domino-Servers zu indizieren. Ursache hierfür ist, daß der
Spider für den Meta-Tag Robots den Parameter None nicht unterstützt. Das liegt daran, daß bei Verity der Spider diesen Meta-Tag vollständig ignoriert und erst der Indexer
kontrolliert, ob er diese Seite indizieren darf. In der nächsten Release von Verity soll
dieses Problem laut Herrn Kehr allerdings behoben werden.
Aufgrund dieser Problematik wurde der erste Testlauf abgebrochen und die Links aus
der Startseite auskommentiert.
Zweiter Testlauf:
Zusätzlich zu den oben genannten Änderungen wurden für diesen Durchlauf noch die
Exclude-Regeln von Verity verändert. Da die Datenbank eine saubere Lösung für Sektionen und kategorisierte Ansichten anbietet, wurden die Werte "Expand" und "Openview&Start=" aus der Exclude-Liste entfernt. Doch auch bei diesem Testlauf begann
der Spider andere Datenbanken zu durchsuchen.
Ursache: Da die Software so konfiguriert wurde (siehe oben), daß bei wiederholten
Durchläufen ein Update durchgeführt wird, geht der Spider nicht von der angegebenen
Startseite aus, sondern arbeitet automatisch alle bereits im Index befindlichen URLs ab.
Daher wurde Verity für einen wiederholten Testlauf angewiesen, eine komplette Neuindizierung vorzunehmen.
Dritter Testlauf:
Anhang
103
Dieser Test verlief auf den ersten Blick positiv. Die Liste der gefundenen Seiten sieht
wie folgt aus:
Abb. 27: Proof of Concept – Trefferliste vom 30.09.1999, Teil 1/2
Anhang
104
Allerdings konnten anhand der Suchergebnisse folgende Fehler identifiziert werden, für
die es zum Teil keine unmittelbare Erklärung gab.
-
Keyword-Test wurde nur einmal indiziert.
-
Index-Test wurde indiziert.
-
About.html und die HTML-Page wurden nicht gefunden.
Lediglich für die Indizierung der Seite Index-Test konnte auf Anhieb eine Erklärung
gefunden werden, da der Robots-Tag auf dieser Seite noch immer auf None gesetzt
war. Leider konnten aus terminlichen Gründen keine weiteren Testläufe vorgenommen
werden, um die aufgetretenen Fehler näher zu untersuchen.
Fazit
Aufgrund der aufgetretenen Fehler bzw. unerklärbaren Phänomene ist eine eingehende
Analyse und ein anschließender weiterer Test erforderlich.
In dieser Analyse konnte die Ursache der Fehler ermittelt werden. Die Links in der
Trefferliste zeigen, daß der Spider nie in der Suchansicht gewesen ist. Auch beim drit-
Anhang
105
ten Suchlauf ist, wahrscheinlich aufgrund einer Fehlkonfiguration, kein neuer Index
angelegt worden, sondern es wurden die Ergebnisse aus dem ersten bzw. zweiten Testlauf benutzt.
Des weiteren haben Tests ergeben, daß bei der Rückgabe des reinen HTTP-Headers der
Meta-Tag HTTP-EQUIV von Domino ignoriert wird (siehe dazu auch Abschnitt 3.2.1).
9.4.2 Protokoll vom 24.11.1999
Datum:
24. November 1999, 10.00-12.00 Uhr
Anwesende der Deutschen Bank AG: Arne Priewe, Jochen Kehr
Für die wiederholten Tests wird Verity zunächst wie beim letzten Termin konfiguriert,
jedoch wird diesmal ein komplett neuer Index angelegt. Auch wird auf allen entsprechenden Seiten und Dokumenenten des Prototyps der Robots-Tag von None auf NoIndex gesetzt.
Aber auch diesmal brach der Spider aus dem Suchbaum aus. Anhand der Logdatei war
schnell ersichtlich, daß der Spider die beim letzten Versuch auskommentierten Links
auf der Startseite verfolgt hat. Darauf hin wurden diese komplett von der Seite entfernt,
und nach Löschung des erstellten Index ein neuer Suchlauf gestartet. Diesmal ergaben
sowohl die Logdatei als auch die Trefferliste der Suchmaschine die erwarteten Ergebnisse (vgl. die Abbildungen auf den folgenden Seiten und Abschnitt 9.4.3).
Anhang
106
Anhang
107
Anhang
108
9.4.3 Logdatei des Verity-Spiders
vspider - Verity, Inc. Version 3.6 (_rs6k41, Sep 23 1998)
Info
11/24 11:39:26 (ind012005) Vspider persistent storage file
</SEARCH/data/inbox/coll_80/indrwdb.dat> opened successfully.
ERROR
11/24 11:39:26 (ind001311) Couldn't lookup host <10.70.5.203> by address [1].
Info
11/24 11:39:26 (ind005005) Licensed for file walking.
Info
11/24 11:39:26 (ind005006) Licensed for local host spidering.
Info
11/24 11:39:26 (ind005007) Licensed for local domain spidering.
Info
11/24 11:39:26 (ind005008) Licensed for remote spidering.
Info
11/24 11:39:27 (ind012202) Analyzing vspider persistent storage --- This may take minutes if you
have a large collection.
Verbose 11/24 11:39:28 (ind010003) Submission enqueued: <http://10.70.5.203/proofofc.nsf/start>.
Progress 11/24 11:39:29 (ind031000) Inserting <http://10.70.5.203/proofofc.nsf/start>.
<http://10.70.5.203/proofofc.nsf/StartPage>.
Progress 11/24 11:39:31 (ind031000) Inserting <http://10.70.5.203/proofofc.nsf/StartPage>.
Verbose 11/24 11:39:35 (ind010003) Submission enqueued: <http://10.70.5.203/proofofc.nsf/search>.
Progress 11/24 11:39:35 (ind031000) Inserting <http://10.70.5.203/proofofc.nsf/search>.
Verbose 11/24 11:39:43 (ind010004) Skipping key
<http://10.70.5.203/ProofofC.nsf/Search/ffec85358a6d65b6c12567ee004d6a2d?OpenDocument&Expand
Section=1> because of VdkVgwKey.
<http://10.70.5.203/ProofofC.nsf/Search/FFEC85358A6D65B6C12567EE004D6A2D?OpenDocument>.
<http://10.70.5.203/ProofofC.nsf/Search/FFEC85358A6D65B6C12567EE004D6A2D?OpenDocument>.
Verbose 11/24 11:39:47 (ind010003) Submission enqueued: <http://10.70.5.203/about.html>.
Progress 11/24 11:39:47 (ind031000) Inserting <http://10.70.5.203/about.html>.
<http://10.70.5.203/ProofofC.nsf/Search/BB385CE48592116CC12567E6005AA686?OpenDocument&da
tabase=Test.nsf>.
<http://10.70.5.203/ProofofC.nsf/Search/BB385CE48592116CC12567E6005AA686?OpenDocument&da
tabase=Test.nsf>.
<http://10.70.5.203/proofofc.nsf/HTMLPage?OpenPage>.
<http://10.70.5.203/proofofc.nsf/HTMLPage?OpenPage>.
<http://10.70.5.203/proofofc.nsf/AttachmentPage?OpenPage>.
<http://10.70.5.203/proofofc.nsf/AttachmentPage?OpenPage>.
Anhang
109
<http://10.70.5.203/proofofc.nsf/StartPage?OpenPage>.
Progress 11/24 11:40:04 (ind031000) Inserting <http://10.70.5.203/proofofc.nsf/StartPage?OpenPage>.
<http://10.70.5.203/ProofofC.nsf/Search/93FF9F39F452D8E2C12567FB00811466?OpenDocument>.
<http://10.70.5.203/ProofofC.nsf/Search/93FF9F39F452D8E2C12567FB00811466?OpenDocument>.
<http://10.70.5.203/ProofofC.nsf/Search/CCD783745ED3C516C12567FB00813760?OpenDocument>.
<http://10.70.5.203/ProofofC.nsf/Search/CCD783745ED3C516C12567FB00813760?OpenDocument>.
<http://10.70.5.203/ProofofC.nsf/Search/CF32B172D7A807DAC12567FB00816886?OpenDocument>.
<http://10.70.5.203/ProofofC.nsf/Search/CF32B172D7A807DAC12567FB00816886?OpenDocument>.
<http://10.70.5.203/ProofofC.nsf/Search/7855DA0624D025CDC12567FB00819E00?OpenDocument>.
<http://10.70.5.203/ProofofC.nsf/Search/7855DA0624D025CDC12567FB00819E00?OpenDocument>.
<http://10.70.5.203/ProofofC.nsf/Search/7FD6CED444CF6E1EC12567FB0081BF48?OpenDocument>.
<http://10.70.5.203/ProofofC.nsf/Search/7FD6CED444CF6E1EC12567FB0081BF48?OpenDocument>.
<http://10.70.5.203/ProofofC.nsf/Search/8BA52E230EABF965C12567FB0081D0FA?OpenDocument>.
<http://10.70.5.203/ProofofC.nsf/Search/8BA52E230EABF965C12567FB0081D0FA?OpenDocument>.
<http://10.70.5.203/ProofofC.nsf/Search/B21353083FB891ADC12567FB0081EF97?OpenDocument>.
<http://10.70.5.203/ProofofC.nsf/Search/B21353083FB891ADC12567FB0081EF97?OpenDocument>.
<http://10.70.5.203/ProofofC.nsf/Search/BF8939C78BB04D3DC12567FB00820207?OpenDocument>.
<http://10.70.5.203/ProofofC.nsf/Search/BF8939C78BB04D3DC12567FB00820207?OpenDocument>.
<http://10.70.5.203/ProofofC.nsf/Search/8235767E6EFFBB1CC12567FB00821DDF?OpenDocument>.
<http://10.70.5.203/ProofofC.nsf/Search/8235767E6EFFBB1CC12567FB00821DDF?OpenDocument>.
<http://10.70.5.203/proofofc.nsf/HTMLPage/$file/about.html>.
<http://10.70.5.203/proofofc.nsf/HTMLPage/$file/about.html>.
<http://10.70.5.203/proofofc.nsf/d63f97457116a3a1c12567fb0079e691/$FILE/1-Introduction.PDF>.
<http://10.70.5.203/proofofc.nsf/d63f97457116a3a1c12567fb0079e691/$FILE/1-Introduction.PDF>.
Anhang
110
<http://10.70.5.203/ProofofC.nsf/d31337db51a63fc1c12567f2007f98e4/93ff9f39f452d8e2c12567fb0081
1466/$FILE/webguide.pdf>.
<http://10.70.5.203/ProofofC.nsf/d31337db51a63fc1c12567f2007f98e4/93ff9f39f452d8e2c12567fb0081
1466/$FILE/webguide.pdf>.
Progress 11/24 11:40:55 (ind010014) Vspider task summary: 22 documents submitted, 0 keys skipped, 0
keys failed.
Verbose 11/24 11:40:56 (ind002103) Inserting 10 keys from BIF
</SEARCH/data/inbox/coll_80/temp/ecb00001.bif> to VDK.
Verbose 11/24 11:40:57 (ind002103) Inserting 12 keys from BIF
</SEARCH/data/inbox/coll_80/temp/ecb00007.bif> to VDK.
Verbose 11/24 11:41:02 (ind002118) Vdk Collection: 10 keys processed.
Progress 11/24 11:41:02 (ind002115) Optimizing VDK collection </SEARCH/data/inbox/coll_80>.
Warn
11/24 11:41:03 (ind002002) VDK: Warn E2-0526 (Document Index): Document 12
(http://10.70.5.203/ProofofC.nsf/d31337db51a63fc1c12567f2007f98e4/93ff9f39f452d8e2c12567fb00811
466/$FILE/webguide.pdf): Sentence 1 in paragraph 0 has more than 255 words - splitting sentence..
Verbose 11/24 11:41:04 (ind002118) Vdk Collection: 12 keys processed.
Progress 11/24 11:41:04 (ind002115) Optimizing VDK collection </SEARCH/data/inbox/coll_80>.
vspider done

Integration von Suchmaschinen in die Corporate Knowledge

Transcription

Similar documents

19991112 - PROJECT CONSULT Unternehmensberatung Dr. Ulrich

copyright by Dr. Joachim Maier, Zollikon (CH) Seite 1

PDF-Download

Full Text

Standortwahl von Unternehmen - Planning of Landscape and Urban

Handbuch Nero BackItUp