1-2

Inhaltsverzeichnis

Inhaltsverzeichnis   1-2

1.  Einleitung  1-5

2.  Grundlagen und Gegebenheiten.  2-8

2.1  Begriff Personalisierung  2-8

2.2  Sicherheitsaspekte und Datenschutz.  2-10

2.2.1  Sicherheitsaspekte bei der Personalisierung.  2-10

2.2.1.1  Personalisierung mittels unabhängiger Nutzerverwaltung.  2-11

2.2.1.2  Personalisierung durch gemeinsame Nutzerverwaltung.  2-12

2.2.2  Datenschutz  2-14

2.2.3  Rechtliche Grundlagen  2-15

2.2.4  Potentielle Gefahren  2-17

2.2.5  Maßnahmen  2-19

2.3  Bekannte Techniken zur Personalisierung.  2-21

2.3.1  Expertengestützte Systeme  2-21

2.3.1.1  Uniforme Bewertung  2-21

2.3.1.2  Regelbasierte Personalisierung.  2-22

2.3.2  Nutzergestützte Systeme.  2-23

2.3.2.1  Einfaches Filtern  2-24

2.3.2.2  Inhaltsbasiertes Filtern  2-24

2.3.2.3  Kollaboratives Filtern (collaborative filtering):  2-25

3.  Konzepte zur Lösung.  3-30

3.1  Datengewinnung  3-31

3.1.1  Technischer Ansatz zur kontinuierlichen Nutzerbeobachtung  3-33

3.1.2  Beschreibung der Funktionsweise  3-35

3.1.2.1  Identifikation der Session bzw. des Nutzers  3-35

3.1.2.2  Identifikation der angeforderten Seite  3-37

3.1.2.3  Identifikation der Aktionselemente  3-40

3.1.2.4  Identifikation aktiver Textdaten  3-44

3.1.2.5  Identifikation passiver Textdaten  3-47

3.1.2.6  Protokollierung der Seitenanforderung  3-50

3.1.2.7  Modifikation des HTML-Quelltextes.  3-52

3.2  Informationsgewinnung  3-54

3.2.1  Informationsgewinnung aus Aktionsdaten  3-54

3.2.1.1  Aktionen.  3-54

3.2.1.2  Seitenwechsel.  3-56

3.2.1.3  Navigationswege.  3-57

3.2.2  Textbasierte Informationen  3-65

3.2.2.1  Verarbeitung von Textdaten  3-66

3.2.2.2  Verarbeitung von textbasierten Informationen  3-77

3.3  Wissensgewinnung  3-81

3.3.1  Wissen über den Nutzer  3-81

3.3.1.1  Erfahrungslevel.  3-82

3.3.1.2  Interessengebiete  3-83

2002  - Kluge/Menzel  1-2

   1-3

3.3.2  Wissen über die Anwendung  3-85

3.3.2.1  Nutzungsschwerpunkte (räumlich/zeitlich)  3-86

3.3.2.2  Zielgruppeninformationen.  3-88

3.4  Integration.  3-89

3.4.1  Metasprache.  3-89

3.4.2  API  3-92

3.5  Anwendung.  3-94

3.5.1  Personalisierung  3-94

3.5.1.1  Sichtbarkeit  3-94

3.5.1.2  Ranking.  3-97

3.5.1.3  Textuelles Ranking.  3-99

3.5.1.4  Hotlinks.  3-102

3.5.1.5  Prefilling  3-104

3.5.1.6  Individuelle Rechtschreibkontrolle  3-106

3.5.1.7  Inhaltsvorschlag.  3-108

3.5.1.8  Zusatzinformationen bei intensiver Nutzung.  3-109

3.5.1.9  Auswahl ähnlicher Inhalte mittels kollaborativen Filterns  3-111

3.5.2  Analysen und Statistiken  3-115

4.  Zusammenfassung und Ausblick  4-120

5.  Anhänge.  5-121

5.1  Grundbegriffe zur Computerlinguistik.  5-121

Abbildungen   5-126

Gleichungen   5-127

Beispiele   5-127

Quellen  , Referenzen und Verweise.  5-130

2002  - Kluge/Menzel  1-3

Ich erkläre an Eides statt, dass ich die vorliegende Arbeit selbständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen nicht benutzt und die den verwendeten Quellen wörtlich oder inhaltlich entnommenen Stellen als solche kenntlich gemacht habe.

Leipzig, 18.02.2002 Stefan Kluge Gerald Menzel

1. Einleitung

Warum finden bis heute Techniken zur Personalisierung nur in so geringem Maß Anwendung im WWW? Eine wesentlicher Grund ist die enorm hohe Technologie- und Kostenhürde, die bisher bei der Realisierung eines personalisierten Angebotes zu überwinden ist. Daneben bestehen zusätzlich oft auch große Vorbehalte gegenüber der Personalisierung. Diese beziehen sich neben dem nur schwer definierbaren wirtschaftlichen Nutzen vor allem auf die Datenschutzproblematik.

Dennoch ist ein Trend hin zum verstärkten Einsatz von Personalisierungstechniken erkennbar. Und das nicht nur im WWW. Diesen wachsenden Bedarf nach entsprechenden Lösungen wird mehr und mehr nachgekommen. Vor allem Hersteller von Systemen im Bereich Content Management (CM) und Customer Relation Management (CRM) bieten mittlerweile immer öfter auch Module mit Personalisierungstechniken. So ist die große Mehrzahl der derzeit am Markt präsenten Lösungen meist nur als Bestandteil oder Erweiterung umfangreicher CM- oder CRM-Lösungen einsetzbar. Der Markt für derartige Systeme ist undurchsichtig und lässt sich aufgrund der Vielfalt und rasanten technologischen Veränderungen der Systeme kaum abgrenzen, weshalb an dieser Stelle bewusst keine Aufstellung oder gar ein Vergleich einzelner verfügbarer Systeme gegeben werden soll. ¹ Beispiele für personalisierte Angebote im WWW sind inzwischen zahlreich zu finden. Das Kürzel ‚my’ weist vielerorts auf die Möglichkeit der persönlichen Anpassung des Angebotes hin, so z.B. myYahoo ² . Ein besonders oft zitiertes Beispiel stellt der Online-Buchversand Amazon ³ dar, welcher schon sehr früh

¹ Dennoch sei auf das Angebot unter www.content-manager.de hingewiesen, welches aktuelle

Informationen und Vergleiche zu Produkten aus den Bereichen CM und CRM bietet.

² www.yahoo.de

³ www.amazon.com / www.amazon.de

auf Personalisierungstechniken gesetzt hat und damit auch sehr erfolgreich war und ist.

Es fällt auf, dass derzeit hauptsächlich größere eCommerce-Angebote den Querschnitt der personalisierten Angebote im WWW bilden. Dies ist wohl vor allem damit zu begründen, dass der Einsatz von Personalisierungstechniken meist wirtschaftlichen Erwägungen (Stichwort: Kundenbindung) folgt und sich die Hersteller solcher Systeme ausschließlich auf dieses lukrative zentrale Marktsegment konzentrieren.

Grenzbereiche finden dagegen bisher kaum Beachtung. Die meisten CM-Systeme sind mit komplexen Verwaltungsfunktionen, wie z.B. Workflow-Koordinierung oder Mitarbeiterverwaltung, ausgestattet und daher für kleinere Anbieter völlig überdimensioniert bzw. nicht finanzierbar. Auch für das andere Ende des Marktes, z.B. Anbieter mit sehr komplexen Angeboten, kommen die derzeit verfügbaren Lösungen kaum in Frage, da diese oft nicht flexibel genug den individuellen Bedürfnissen angepasst werden können. Es besteht also Bedarf nach Personalisierungslösungen, die unabhängig von CM-Systemen einsatzfähig sind. Eine solche Lösung müsste leicht und mit nur geringem Aufwand in bestehende Angebote integrierbar, gleichzeitig aber auch flexibel anzupassen und einsetzbar sein. Es müssten damit sowohl komplett dynamische Websites personalisiert werden können als auch Angebote, die teilweise oder gänzlich aus statischen HTML-Dateien bestehen. Dem Personalisierungssystem sollte ein offenes und dadurch transparentes Konzept zugrunde liegen, um Datenschutzbedenken entgegenwirken zu können.

Im Folgenden werden Ansätze für ein solches innovatives Personalisierungskonzept vorgestellt. Eine besondere Rolle spielen dabei auch Methoden der Computerlinguistik. ⁴ Im Gegensatz zu herkömmlichen Systemen wird ein nicht-integrativer Ansatz, d.h. eine klare Trennung zwischen

⁴ Einige Grundbegriffe der Computerlinguistik werden im Anhang näher erläutert.

Personalisierungssystem und der zu personalisierenden Anwendung, verfolgt. Diese Arbeit untersucht die Möglichkeiten der Informationsgewinnung und skizziert Anwendungsfälle für eine Personalisierung auf Basis dieser Informationen.

2. Grundlagen und Gegebenheiten

2.1 Begriff Personalisierung

Vor dem ‚Wie’ sollen zu Beginn zunächst die Fragen ‚Was ist Personalisierung?’ und ‚Wer braucht sie?’ geklärt werden. Erstere Frage ist nicht leicht zu beantworten, denn es existieren viele verschiedene Definitionen zum Begriff ‚Personalisierung’ in unterschiedlichen Kontexten. Bezogen auf das Feld der Informationsverarbeitung könnte eine intuitive Definition vielleicht folgendermaßen lauten: ‚Personalisierung bedeutet die Anpassung von Inhalten für ein konkretes Subjekt, z.B. durch Hinzufügen von für dieses Subjekt interessanten und Weglassen von uninteressanten Informationen.’ Ein solches ‚konkretes Subjekt’ könnte als eine reale Person oder auch als eine Gruppe von Personen verstanden werden. Tatsächlich existieren aber auch hier teilweise sehr verschiedene Definitionen. So findet der Begriff Personalisierung u.a. im Bereich eCommerce Verwendung und meint dort oft nichts anderes als die Möglichkeit, sich als Kunde mit Name, Adress- und Kontoverbindungsdaten zu registrieren, um diese bei späteren Bestellungen nicht erneut eingeben zu müssen. Es bedarf also einer allgemeinen (allumfassenden) Definition des Begriffes Personalisierung für das Feld der Informationsverarbeitung.

Personalisierung bedeutet eine positive Beeinflussung der Art und Weise, wie Information für eine konkrete Person zugänglich ist. Dies schließt z.B. auch die Möglichkeit der Vorauswahl von Informationen ein, abhängig von den Präferenzen der Person - in Anbetracht der zunehmenden Informationsflut eine nicht zu unterschätzende Stärke personalisierter Informationssysteme. Bei der Entwicklung von Informationssystemen wie z.B.

Anwendungsprogrammen, aber auch Angeboten im WWW, wurde bisher meist

von einer allgemeinen Zielgruppe ausgegangen, welche, abhängig vom Charakter des Systems, mehr oder weniger groß ist. Der Gruppe werden gewisse Eigenschaften zugeschrieben und diese als für jedes Individuum der Gruppe zutreffend angenommen. Anhand dieses Eigenschaftskataloges findet die Ausrichtung der Schnittstellen und Inhalte des Systems statt. Die Anpassung an den Nutzer (die Zielgruppe) ist also statisch, d.h. einmalig, bei der Entwicklung des Angebotes. Naturgemäß können so jedoch nur elementare und wenig differenzierte Eigenschaften von Personen berücksichtigt werden. Dies sind in den meisten Fällen Eigenschaften wie z.B. Alter, Bildungsstand, Interessengruppe usw.

Im Gegensatz zu diesem klassischen Zielgruppenkonzept, verfolgt die Personalisierung den Gedanken, jeden einzelnen Nutzer als Individuum zu behandeln und die Schnittstellen und Inhalte des Informationssystems nach dessen persönlichen Eigenschaften anzupassen. Natürlich bedeutet dies, dass das Personalisierungssystem Kenntnis der persönlichen Eigenschaften jedes Nutzers haben muss. Diese Daten können auf verschiedene Weise gewonnen werden, vom einfachen Fragebogen bis hin zur automatischen Beobachtung und Auswertung aller Aktionen der Nutzer des Informationssystems. Letzteres Verfahren ist nur mit enormem technischem Aufwand realisierbar, birgt aber großes Potenzial, da sich aus den so gesammelten Daten sehr viele Informationen zu Eigenschaften der Nutzer gewinnen lassen, was wiederum sehr komplexe und effiziente Personalisierungstechniken ermöglicht. Jedoch müssen persönliche Daten als sensibel eingestuft werden. Begriffe wie ‚Nutzerbeobachtung’ oder ‚Profilerstellung’ können leicht missverstanden werden. Dies fügt der technischen Problematik auch noch einen heiklen rechtlichen Aspekt hinzu und macht die Personalisierung zu einem kontrovers diskutierten Thema. Das folgende Kapitel setzt sich daher zunächst näher mit der Datenschutzproblematik auseinander.

2.2 Sicherheitsaspekte und Datenschutz

2.2.1 Sicherheitsaspekte bei der Personalisierung

Berichtet man von Techniken zur Ermittlung von Nutzergewohnheiten, zur Erstellung von Nutzerprofilen oder zur Individualisierung eines Interfaces, so wird man oft konfrontiert mit Kommentaren wie "Spyware", "Datenspionage" oder "ich will nicht, dass sich meine Oberfläche verändert". An dieser Stelle muss man unterscheiden zwischen der Skepsis über die Qualität eines solchen Systems, die zur vorschnellen Ablehnung führen kann, und über Bedenken bezüglich Datenschutz und Anonymität.

Gründe für das Misstrauen gegenüber einer Interface-Individualisierung können verschiedener Natur sein. Viele Nutzer, vor allem im professionellen Bereich, haben schlechte Erfahrungen mit solchen Techniken gemacht. So sind einige in Microsoft Windows bzw. in den Microsoft Office Produkten integrierten Personalisierungstechniken für bestimmte Zielgruppen nicht geeignet oder sogar produktivitätsmindernd. Als konkretes Beispiel sei an dieser Stelle die Funktion zum automatischen Verbergen selten genutzter Menüpunkte genannt, die in modernen Microsoft Office Produkten integriert ist. Während durchschnittlichen Nutzern durch diese Funktion eine größere Übersichtlichkeit gegeben wird, fühlen sich zahlreiche fortgeschrittene Anwender durch die zusätzlich notwendige Erweiterung der jeweils eingeblendeten Menüleiste, um verborgene Menüpunkte nutzen zu können, behindert. Microsoft hat mit seiner hohen Marktdurchdringung einen großen Einfluss auf die öffentliche Meinungsbildung. Daher sind diese für bestimmte Zielgruppen mangelhaften Konzepte nicht unwesentlich für das Misstrauen dieser Nutzer mitverantwortlich.

Für viele Kritiker sind Bedenken bezüglich der Datenspionage und des Anonymitätsverlustes Gründe für eine Zurückhaltung. Diese Bedenken sind

natürlich nicht von der Hand zu weisen. Jedoch muss berücksichtigt werden, dass die Gewährleistung dieser Sicherheit von einem konkreten System abhängt und nicht zu einer Pauschal-Verurteilung der Personalisierung an sich führen kann. Nun ist es Nutzern von personalisierten Systemen allerdings in der Regel nicht möglich, diese auf Einhaltung diverser Sicherheitsanforderungen zu prüfen. Allerdings ist bereits ein Trend erkennbar, dass sich namhafte Firmen immer öfter um eine freiwillige Sicherheitskontrolle durch mehr oder weniger unabhängige Experten, wie dem TÜV für IT-Security, bemühen. In dieser Arbeit werden modulare Personalisierungssystemkonzepte favorisiert. Es handelt sich dabei um Konzepte, die eine unkomplizierte Erweiterung bestehender Systeme um eben diese Personalisierungskomponente ermöglichen. Sicherheitsaspekte, die für eine konkrete Anwendung dieser Personalisierung relevant sind, müssen nicht zwangsläufig auch für die Personalisierung an sich eine Bedeutung haben. Die gewährleistbare Sicherheit hängt vor allem von der Schnittstelle zwischen dem Personalisierungssystem und der Anwendung ab. Von den Autoren wird im Folgenden ein mehrstufiges Sicherheitskonzept vorgestellt.

2.2.1.1 Personalisierung mittels unabhängiger Nutzerverwaltung Nutzer des Personalisierungssystems werden völlig losgelöst von den Nutzern der Anwendung betrachtet. Es gibt keinerlei Austausch von Nutzeridentifikationsnummern oder sonstigen Daten, die eine Verbindung zwischen Nutzerdaten des Personalisierungssystems und Nutzerdaten der Anwendung ermöglichen. Damit ist es nicht möglich, Wissen über den Nutzer innerhalb des Personalisierungssystems, auf eine reale Person zu übertragen, da eine Verbindung zur realen Person, wenn überhaupt, nur in der Anwendung existiert. So wäre dies z.B. möglich, wenn in der zu personalisierenden Anwendung Adressinformationen archiviert würden und eine Abkopplung zwischen Nutzer im Personalisierungssystem und Nutzer der Anwendung nicht vorliegen würde.

Vorteil dieser Methode ist die völlige Anonymität personalisierter Daten. Es ist z.B. nicht möglich, Wissen über das Erfahrungslevel eines Nutzers auf eine reale Person zu übertragen. Da dies aus Marketinggründen auch erwünscht sein kann, ist es unter Umständen ebenso ein Nachteil. Ein erheblicher Nachteil kann die mangelhafte Nutzererkennung sein. Das Einloggen ist die einzig sichere und praktikable Möglichkeit zur Identifikation eines Nutzers, da die jeweilige Person sich aktiv auf einem beliebigen Rechner mittels Benutzername und Passwort identifiziert. Für das Personalisierungssystem ist dieses Verfahren in diesem Fall jedoch nicht von Nutzen, daher muss die Identifikation auf der Verwendung von Cookies bzw. nicht persistenten Session-IDs basieren. Cookies sind Dateien, die von einem Server auf dem Client gespeichert werden, wo sie vom Webbrowser verwaltet werden. Diese Dateien können beispielsweise eine Nutzeridentifikationsnummer dauerhaft speichern. Da Cookies durch Nutzer blockierbar sind, kann eine Wiedererkennung von Nutzern nicht garantiert werden. Nicht persistenten Session-IDs sind, wie der Name schon sagt, nur für die Dauer eine Session gültig. Eine solche eindeutige ID wird einem Nutzer bei der ersten Anfrage vergeben und dann bei jeder weiteren Anfrage dieses Nutzers weitergereicht. Für eine Personalisierung ist dieses Verfahren nur bedingt geeignet, da wiederkehrende Nutzer nach Beendigung einer Session nicht wiedererkannt werden können.

Sinnvoll ist die Anwendung der unabhängigen Nutzerverwaltung, wenn im zu personalisierenden System ohnehin keine Nutzerverwaltung implementiert ist. Außerdem gibt es Online-Angebote, die die Annahme von Cookies durch Ihre Anwender voraussetzen. Auch in diesem Fall ist der Einsatz möglich und voraussichtlich nur geringfügig durch mangelhafte Nutzererkennung beeinträchtigt.

2.2.1.2 Personalisierung durch gemeinsame Nutzerverwaltung Websites mit eigener Nutzerverwaltung können diese über die

Schnittstelle zum Personalisierungssystem propagieren. Technisch kann dies

vereinfacht als „Durchreichen“ einer eindeutigen Nutzeridentifikationsnummer verstanden werden. Vorteilhaft ist in diesem Fall die eindeutige Nutzererkennung durch Login. Die Möglichkeit, eine Verbindung zwischen nutzerbezogenen Daten des Personalisierungssystems und denen der Anwendung zu schaffen, kann aus Marketing-Sicht erhebliche Vorteile bringen. So können Anwendungsfunktionalitäten implementiert werden, deren Realisierung mit Hilfe einer Personalisierungsmetasprache nicht möglich wäre. Als Beispiel sei das Verschicken von personalisierten Newslettern genannt. Als Nachteil ist der Verlust der Anonymität personalisierter Informationen zu nennen, wenn Informationen zur realen Person in der Anwendung vorliegen. Generell soll hier darauf hingewiesen werden, dass Nutzerdaten bezüglich einer Personalisierung in dem von uns vorgestellten Sinne im Allgemeinen keine sensiblen persönlichen Informationen sind. Bei einer Diskussion sollte im Auge behalten werden, dass es sich nicht um Konto-, Adress- oder sonstige Informationen mit direktem Bezug zur realen Person handelt. Die Informationen, die auf der Basis des hier vorgestellten Personalisierungskonzeptes gewonnen werden, sind vielmehr als abstraktes Wissen, etwa in Form von Navigationsverhaltensregeln bezüglich einer Website, oder in Form von Interessenschwerpunkten, bezogen auf dynamische Informations-Cluster, zu verstehen.

Einer Entscheidung für eines der beiden Sicherheitskonzepte sollten folgende Überlegungen vorausgehen:

I. Anforderungen an die Personalisierung

Wird das Personalisierungssystem vorwiegend zur Analyse des Kundenverhaltens eingesetzt? Oder kommen aktive Personalisierungsfunktionen zum Einsatz, die beispielsweise Inhalte und Form der Anwendung beeinflussen? Dann spricht dieser Fakt für eine Personalisierung durch gemeinsame Nutzerverwaltung.

II. Nutzerverwaltung der Anwendung

Existiert in der zu personalisierenden Anwendung eine Nutzerverwaltung? Ist dies nicht der Fall, so kommt eine gemeinsame Nutzerverwaltung ohnehin nicht in Frage.

III. Sicherheitsanforderungen an die Anwendung

Bei der Implementierung einer Personalisierungslösung in Anwendungen mit strikten Sicherheitsbestimmungen kann es, z.B. auch aus

unternehmenspolitischen Gründen, gefordert werden, die Nutzeridentifikation nicht an ein externes Modul weiterzugeben. Auch in diesem Fall kann keine gemeinsame Nutzerverwaltung zum Einsatz kommen.

2.2.2 Datenschutz

Folgende Betrachtungen des Datenschutzes spielen nur dann eine Rolle, wenn es sich bei den verarbeiteten Daten um personenbezogene Daten handelt. "Personenbezogene Daten sind Einzelangaben über persönliche oder sachliche Verhältnisse einer bestimmten oder bestimmbaren natürlichen Person (Betroffener)." ⁵ Abhängig vom Einsatz eines Personalisierungssystems ist eine Verbindung zwischen verarbeiteten Daten eines Nutzers und der entsprechenden natürlichen Person nicht immer notwendig. Die Bestimmbarkeit einer natürlichen Person kann dadurch verhindert werden, dass eine solche Verbindung gar nicht erst hergestellt wird. So können Daten über das Navigationsverhalten eines Nutzers verarbeitet werden, ohne dabei Daten über die natürliche Person, die sich hinter diesem Nutzer verbirgt, festzuhalten. In einem solchen Fall spielen rechtliche Grundlagen des Datenschutzes keine Rolle. Da bei einem Personalisierungssystem jedoch eine Verbindung zwischen verarbeiteten Daten und den jeweiligen natürlichen Personen auch gewünscht sein kann, sollen gesetzliche Regelungen an dieser Stelle nun genauer betrachtet werden.

⁵ § 3 BDSG

2.2.3 Rechtliche Grundlagen

Die rechtlichen Grundlagen des Datenschutzes in Deutschland sind im Bundesdatenschutzgesetz (BDSG) ⁶ festgehalten. Speziell im Internet-Bereich (TDG) ⁷ , spielen außerdem das Teledienstegesetz das

Teledienstedatenschutzgesetz (TDSSG) ⁸ und der Mediendienstestaatsvertrag (MDStV) ⁹ eine Rolle. Im Rahmen eines Urteils des Bundesverfassungsgerichts wurde 1983 erstmals der Begriff der Informationellen Selbstbestimmung (ISR) geprägt, welcher grundlegende Bedeutung für die datenschutzrechtliche Gesetzgebung hat. Es wird argumentiert, dass ein Bürger in seiner Freiheit wesentlich gehemmt sein kann, wenn für ihn nicht überschaubar ist, welche Informationen seiner Umwelt über ihn bekannt sind. Folgende gesetzliche Vorgaben sollten bei der Konzeption eines Personalisierungssystems beachtet werden: Es dürfen nur Daten verarbeitet werden, die für den konkreten Fall erforderlich sind (Datensparsamkeit). Daten müssen zweckgebunden gesammelt und vor Zugriffen unberechtigter geschützt werden (Zweckbindung). Personen haben das Recht zu erfahren, welche personenbezogenen Daten über Sie gespeichert werden und zu welchem Zweck dies geschieht. Außerdem können betroffene Personen die Berichtigung, Löschung oder Sperrung der Daten fordern. Die Datenverarbeitung muss so organisiert werden, dass Sie nachvollziehbar ist (Transparenz). Dazu gehört auch die Unterrichtung der betroffenen Personen vor der Erhebung der Daten. Angaben über die rassische und ethnische Herkunft, politische Meinungen, religiöse oder philosophische Überzeugungen,

Gewerkschaftszugehörigkeit, Gesundheit oder Sexualleben unterliegen schärferen Bestimmungen.

⁶ http://www.datenschutz-berlin.de/recht/de/bdsg/bdsg1.htm (abgerufen am 17. Februar 2002)

⁷ http://www.bfd.bund.de/information/info5/info5011.htm (abgerufen am 17. Februar 2002)

⁸ http://www.bfd.bund.de/information/info5/info5012.htm (abgerufen am 17. Februar 2002)

⁹ http://www.iid.de/iukdg/gesetz/mdstv.html (abgerufen am 17. Februar 2002)

Der folgende Ausschnitt der BDSG [§ 46] weist auf einige für die Organisation der Datenverarbeitung wichtigen Anforderungen hin: "1. Unbefugten den Zutritt zu Datenverarbeitungsanlagen, mit denen personenbezogene Daten verarbeitet oder genutzt werden, zu verwehren (Zutrittskontrolle),

2. zu verhindern, dass Datenverarbeitungssysteme von Unbefugten genutzt werden können (Zugangskontrolle), 3. zu gewährleisten, dass die zur Benutzung eines

Datenverarbeitungssystems Berechtigten ausschließlich auf die ihrer Zugriffsberechtigung unterliegenden Daten zugreifen können, und dass personenbezogene Daten bei der Verarbeitung, Nutzung und nach der Speicherung nicht unbefugt gelesen, kopiert, verändert oder entfernt werden können (Zugriffskontrolle),

4. zu gewährleisten, dass personenbezogene Daten bei der elektronischen Übertragung oder während ihres Transports oder ihrer Speicherung auf Datenträger nicht unbefugt gelesen, kopiert, verändert oder entfernt werden können, und dass überprüft und festgestellt werden kann, an welche Stellen eine Übermittlung personenbezogener Daten durch Einrichtungen zur Datenübertragung vorgesehen ist (Weitergabekontrolle), 5. zu gewährleisten, dass nachträglich überprüft und festgestellt werden kann, ob und von wem personenbezogene Daten in Datenverarbeitungssysteme eingegeben, verändert oder entfernt worden sind (Eingabekontrolle), 6. zu gewährleisten, dass personenbezogene Daten, die im Auftrag verarbeitet werden, nur entsprechend den Weisungen des Auftraggebers verarbeitet werden können (Auftragskontrolle), 7. zu gewährleisten, dass personenbezogene Daten gegen zufällige Zerstörung oder Verlust geschützt sind (Verfügbarkeitskontrolle),

8. zu gewährleisten, dass zu unterschiedlichen Zwecken erhobene Daten getrennt verarbeitet werden können."

2.2.4 Potentielle Gefahren

Unberechtigter Zugang zu den Daten

Um nur berechtigten Personen den Zugang zu einem personalisierten System zu ermöglichen, bietet sich ein Passwortschutz an. Abhängig von der konkreten Implementierung wird dies möglicherweise nicht in der Zuständigkeit des Personalisierungssystems liegen, sondern bereits von der zu personalisierenden Anwendung selbst übernommen - zum Beispiel einem Internet-Portal, welches ein Login vorsieht.

Missbrauch der Daten

Die Verwendung von personenbezogenen Daten für nicht vorgesehene Zwecke wiederspricht der gesetzmäßigen Zweckbindung. Für ein Personalisierungssystem bedeutet dies, dass bei der Formulierung des Verwendungszweckes gegenüber den Benutzern entsprechend sorgfältig vorgegangen werden muss. Einerseits erfordert die angestrebte und für das Vertrauen des Nutzers notwendige Transparenz eine deutliche Formulierung des Verwendungszweckes der Daten. Andererseits machen ökonomische Gesichtspunkte eine Skalierbarkeit und Flexibilität eines

Personalisierungssystems und der entsprechend verarbeiteten Daten notwendig. Auch hier gilt es eine Verhältnismäßigkeit zu wahren. Das heißt, vor allem bei der Verarbeitung sensibler persönlicher Daten den Verwendungszweck besonders unmissverständlich zu formulieren und ihm strikt zu entsprechen. Schutz vor Datenmissbrauch heißt weiterhin, Maßnahmen zu ergreifen um Unberechtigten den Zugang zu diese Daten zu verwehren. Diese Maßnahmen hängen jedoch stark von der konkreten Anwendung und dem jeweiligen System

ab und bedürfen einer individuellen Integration in das entsprechende Sicherheitskonzept.

Manipulation der Daten

Im Gegensatz zur Manipulation etwa von Kontodaten in einer Onlinebanking-Anwendung hat die Veränderung der Daten eines Personalisierungssystems (nur) dessen Fehlfunktion zur Folge. Man muss sich darüber im Klaren sein, dass die Daten der jeweiligen Anwendung völlig unabhängig von den Daten des Personalisierungssystems sind. Eine Manipulation wirkt sich also nicht in der Form aus, dass etwa eine Überweisung innerhalb einer Onlinebanking-Anwendung ein falsches Konto erreichen würde, allerdings wären Fehlfunktionen innerhalb des vom Personalisierungssystem gesteuerten individuellen Nutzer-Interfaces möglich. Wie auch beim Schutz gegen Missbrauch der Daten muss einer Manipulation bereits bei der Integration in das gesamte Sicherheitskonzept der Zielanwendung vorgebeugt werden. Andererseits können auch Anwendungsunabhängige Maßnahmen die Sicherheit des Personalisierungssystems erhöhen. So zum Beispiel die Bildung einer Checksumme über gefährdete Daten, welche dann bei der Verwendung dieser Daten als Dekodierungsschlüssel dient.

Gefahr durch Verknüpfung von Daten

Auch wenn personenbezogene Daten isoliert betrachtet keine unrechtmäßig erlangten Informationen darstellen, so muss beachtet werden, dass die Verknüpfung dieser Daten möglicherweise weitergehende Rückschlüsse zulassen. Ob eine Verknüpfung möglich ist, muss für jedes Datum anhand der konkreten Anwendung geprüft werden. Auch hier gilt der Grundsatz der Verhältnismäßigkeit. So ist die Verknüpfung von IP-Adresse und der entsprechenden natürlichen Person theoretisch zwar möglich, jedoch nur mit erheblichem Aufwand durchsetzbar. Damit ist die Verarbeitung der IP-Adresse im Regelfall vertretbar.

2.2.5 Maßnahmen

Passwort-Schutz

Passwörter gelten als guter Kompromiss zwischen Sicherheit und Benutzerfreundlichkeit. Es lässt sich in jedem Fall folgende Empfehlung für Passwort-Schutzmechanismen aussprechen ¹⁰ :Passwörter sind im System verschlüsselt abzulegen und gegen unbefugte Zugriffe zu schützen

• wiederholte Falscheingaben sind zu unterbinden, z.B. durch Sperrung nach dreimaliger Falscheingabe

• Passwörter sollten eine Mindestlänge von 6 Zeichen haben und aus einem alphanumerischen Zeichenmix bestehen.

• Die Eingabe sollte verdeckt erfolgen, das Anzeigen von Ersatzzeichen (*) lässt die Erkennung der Passwortlänge für Dritte zu.

• Falscheingaben sollten dem Nutzer sofort mitgeteilt und vom System protokolliert werden.

• Die Nutzung von Trivialpasswörtern sollte vom System unterbunden werden.

Bei den Maßnahmen ist jeweils abzuwägen, wie stark die Benutzbarkeit des Systems darunter leidet und wie groß der organisatorische Aufwand ist. So ist die Vorgabe einer Mindestlänge von 8 Zeichen zwar der Sicherheit zuträglich, nicht jedoch der Usability. Ebenso ist es einem Systembetreiber unter Umständen aus ökonomischen Gesichtspunkten nicht möglich, bei einer Sperrung eines Nutzer-Profils eine Entsperrung nur nach Kontaktaufnahme mit der jeweiligen Person vorzunehmen. Der Sicherheitsaufwand sollte vor allem im Verhältnis zu den verarbeiteten personenbezogenen Daten stehen.

¹⁰ siehe auch: http://www.datenschutz-berlin.de/infomat/ratgeber/3ratgeb.htm (abgerufen am

17. Februar 2002)

Verschlüsselung

Passwörter und andere sensible Daten müssen angemessen verschlüsselt werden. Dies gilt auch für die Übertragung dieser Daten. Generell ist es empfehlenswert, sich dabei an standardisierten Konzepten zu orientieren, zum Beispiel einer Verschlüsselung gemäß des Advanced Encryption Standard (AES) ¹¹ und einer Übertragung über Secure Socket Layer (SSL) ¹² .

Transparenz

Platform for Privacy Preferences (P3P) ¹³ ist ein Protokoll zur Beschreibung von Daten-Sammlungs-Praktiken einer Website. Dieses Protokoll dient sowohl der Information der Nutzer über private Daten, die auf einer Website über ihn gesammelt werden, als auch der automatischen Verarbeitung dieser Informationen durch den Webbrowser. Browser, die dies unterstützen, können einen automatischen Vergleich mit den Sicherheitseinstellungen der Nutzer vornehmen und den Nutzer ggf. warnen. Microsoft hat diese Unterstützung im IE 6 integriert. P3P ist als Empfehlung des W3C ein offener Standard und kann als vertrauensschaffende Maßnahme dem Betreiber einer Personalisierungstechnik nutzenden Website empfohlen werden. Da das Personalisierungssystem jedoch unabhängig von persönlichen Nutzerdaten arbeitet, ist dies nur indirekt ein Aspekt des Datenschutzes. Indirekt deshalb, weil zu vermuten ist, dass viele Benutzer ein generelles Misstrauen gegenüber personalisierten Systemen aufbringen werden und gerade deshalb durch Transparenz Vertrauen aufgebaut werden sollte.

¹¹ http://csrc.nist.gov/encryption/aes/ (abgerufen am 17. Februar 2002)

¹² http://www.netscape.com/eng/ssl3/ (abgerufen am 17. Februar 2002)

¹³ http://www.w3.org/P3P/ (abgerufen am 10. Dezember 2001)

2.3 Bekannte Techniken zur Personalisierung

Den Kern eines jeden Personalisierungssystems bilden Methoden und Verfahren, die auf verschiedenste Art und Weise die Beziehungen zwischen den Inhalten der Anwendung und deren Nutzern analysieren und beeinflussen - die eigentlichen Personalisierungstechniken. Es existieren verschiedene Ansätze für solche Techniken, wobei die Struktur der Inhalte des Angebotes und der Nutzergruppen bestimmend für die Qualität der erzielten Ergebnisse ist.

2.3.1 Expertengestützte Systeme

2.3.1.1 Uniforme Bewertung

Bei der Personalisierung mit Hilfe uniformer Bewertungssysteme werden dem Nutzer Entscheidungshilfen zur Auswahl von Inhalten, z.B. zum Kauf eines Produktes oder zur Wahrnehmung einer Dienstleistung, geboten. Die Entscheidungshilfen orientieren sich dabei nicht an den individuellen Präferenzen des Nutzers, sondern an denen der Allgemeinheit, also aller Nutzer. Definition: Uniforme Präferenzen liegen vor, wenn ein großer Prozentsatz der Nutzer identische Merkmale eines Produktes oder einer Dienstleistung schätzt.

¹⁴ Quelle: Hanson 2000

Uniforme Bewertungssysteme sind nicht automatisierbar, d.h. die benötigten Daten werden manuell erhoben. Alle Inhalte müssen durch Nutzerbefragungen, Expertenanalysen oder ähnliche Verfahren regelmäßig neu bewertet werden. Das bedeutet auch, dass sich nicht alle Arten von Inhalten für diese Technik eignen, so z.B. Inhalte mit emotionalen Aspekten.

2.3.1.2 Regelbasierte Personalisierung

Bei der Personalisierung mit Hilfe regelbasierter Systeme werden die über den Benutzer gesammelte Informationen einem Satz von Regeln gegenübergestellt und anhand dieser Regeln ausgewertet. Ein solches Expertensystem ist, wie der Name schon sagt, mit dem Schlussfolgern und Handeln eines Experten vergleichbar.

Die zugrunde liegenden Regeln sind häufig nach folgendem Muster aufgebaut: Folgerung←(Bedingung1=wahr)∧(Bedingung2=wahr)∧... Damit lassen sich Bedingungen definieren, wie z.B.: „Zeigt Nutzer verstärkt Interesse an >Outdoor<, >Camping< und

>Gebirge<, dann zeige Bannerwerbung einschlägiger Reiseveranstalter.“

Ein komplexes regelbasiertes Personalisierungssystem besteht aus einer Wissensbasis mit Fakten (Sachverhalte, dargestellt durch Objekt-Attribut-Wert Trippel) und Regeln (in if/then-Struktur), einer Inferenzmaschine (enthält den Schlussfolgerungsmechanismus), einem Wissenserwerbs-Subsystem, einem Erklärungs-Subsystem und einer Benutzerschnittstelle.

Voraussetzung für den Betrieb eines regelbasierten Informationssystems ist ein umfangreiches Inhalts- und Zielgruppen-Know-How seitens des Betreibers, da dieser für die Aufstellung und Pflege der Regeln zuständig ist. Der große Vorteil eines solchen Systems ist die hohe Flexibilität der Personalisierung durch beliebige Verknüpfungsmöglichkeiten von Fakten und Bedingungen, woraus auch eine gute Überschau- und Steuerbarkeit resultiert. Diese Vorteile werden allerdings durch einen hohen konzeptionellen Initialaufwand (z.B. Aufstellung der Regelbasis) und die Notwendigkeit einer permanenten - meist manuellen - Aktualisierung erkauft.

2.3.2 Nutzergestützte Systeme

Grundlegendes Arbeitsprinzip der meisten nutzergestützten

Personalisierungssysteme (Cognitive- ,Economic- und Social Filtering) ist der Einsatz mehr oder weniger komplexer Filtertechniken. Neben einfachen Filtern lassen sich diese Verfahren hauptsächlich in inhaltsbasierte und bewertungsbasierte Filterverfahren unterteilen. Nutzergestützte

Personalisierungssysteme lassen sich oft auch sehr gut mit regelbasierten Systemen kombinieren.

2.3.2.1 Einfaches Filtern

Wie der Name vermuten lässt, handelt es sich hierbei um ein sehr simples Verfahren. Jeder Nutzer wird dabei einer manuell definierten Gruppe zugeordnet und die Eigenschaften dieser Gruppe als für ihn zutreffend angenommen. Beispiel:

„Kunden, die der Gruppe >Premium-Kunden< zugeordnet sind, werden bestimmte Rabatte angeboten.“

Dieses Verfahren erfordert weder einen hohen Initial-, noch eine hohen Aktualisierungsaufwand. Allerdings lassen sich damit auch nur einfachste Personalisierungstechniken realisieren.

2.3.2.2 Inhaltsbasiertes Filtern

Inhaltsbasierte Filtertechniken (auch Cognitive/Content Based Filtering genannt) stellen bereits fortgeschrittenere Methoden zur Personalisierung dar und produzieren gegenüber dem einfachen Filtern schon wesentlich komplexere Ergebnisse.

Grundlegendes Prinzip ist eine Klassifizierung aller Inhalte (z.B. Produkte) des Informationssystems. Dies geschieht, indem jedem Inhalt eine Menge von zutreffenden Attributen zugeordnet wird. Durch Vergleich dieser Attribute lassen sich dann wiederum ähnliche Inhalte einander zuordnen. Die Ermittlung der Präferenzen des Nutzers geschieht durch Beobachtung seiner Auswahl von Inhalten. So können ihm z.B. passende (ähnliche) Inhalte vorgeschlagen werden.

Voraussetzung dafür ist allerdings eine ausreichend gute Klassifizierung der Inhalte. Als Vorteil zeigt sich hier, dass sich diese Klassifizierung in der Regel natürlich ergibt. Leider lassen sich aber eben nicht alle Arten von Inhalten gut klassifizieren. Schwierigkeiten treten z.B. bei Bildern oder Düften auf, da sich solchen Inhalten nur schwer Attribute zuordnen lassen. In jedem Fall ist für die Klassifizierung der Inhalte ein hoher Initialaufwand notwendig.

2.3.2.3 Kollaboratives Filtern (collaborative filtering):

Die Anfänge dieser Technik liegen in den neunziger Jahren. Forschungen an der Universität von Minnesota verfolgten damals das Ziel, die großen Mengen von Beiträgen in Newsgroups zu filtern, um dem Nutzer zu ermöglichen, leichter die für ihn interessanten Beiträge zu finden. Das daraus entstandene Filtersystem war in der Lage, den Nutzerbestand automatisch in passende Gruppen zu gliedern - die „Group Lens“ ¹⁵ Das so genannte kollaborative Filtern stellt eine der fortgeschrittensten Filtertechniken dar. Grundlage ist hier nicht eine Klassifizierung der Inhalte, sondern die Beziehung von Nutzern zu Inhalten. Diese Beziehung entsteht, indem Nutzer die Inhalte bewerten. Das kann zum einen aktiv (manuell) geschehen, z.B. durch die Vergabe von Bewertungspunkten durch den Nutzer, oder auch passiv (automatisch). In letzterem Fall muss der Nutzer nicht direkt in Anspruch genommen werden. Vielmehr vergibt er die Bewertungen unbewusst, d.h. schon die bloße Auswahl von Inhalten durch den Nutzer kann als Bewertung interpretiert werden.

Anhand ähnlicher Bewertungsmuster können alle Nutzer dynamisch gebildeten Gruppen (sog. Peer-Gruppen) zugeordnet werden. Jede dieser Gruppen erhält gewisse Eigenschaften, gebildet aus der Summe der Eigenschaften aller der jeweiligen Gruppe zugehörigen Nutzer. Jede der so gewonnenen Eigenschaften einer Gruppe wird nun auch als für jedes Mitglied der Gruppe zutreffend angenommen.

¹⁵ siehe auch: http://www.cs.umn.edu/Research/GroupLens/index.html (abgerufen am 7.

Januar 2002)

Ein bekanntes Beispiel stellt hier der Online-Buchhandel amazon.de ¹⁶ dar. Dieser nutzt die Technik des kollaborativen Filterns z.B. für die Empfehlung von Buchtiteln.

Die für den Einsatz des kollaborativen Filterns notwendigen Daten können mit Hilfe verschiedenster Techniken gewonnen werden. Zu nennen sei hier vor allem die Technik der Nutzerbeobachtung (Usertracking), auf die später noch näher eingegangen wird.

Da das kollaborative Filtern die zurzeit wohl fortgeschrittenste Technik darstellt, soll hier auf verschiedene bekannte Algorithmen näher eingegangen werden:

Speicherbasiert (Memory-Based)

Bei dieser Technik werden immer alle zugrunde liegenden Daten für die Generierung von Empfehlungen genutzt. Der gesamte Bestand an Bewertungsdaten wird nach Nutzern mit ähnlichem Bewertungsmuster durchsucht. Als Maß für die Ähnlichkeit könnte dabei z.B. der Korrelationskoeffizient nach Pearson dienen.

¹⁶ http://www.amazon.de (abgerufen am 20. Januar 2002)

Dieser ist wie folgt definiert:

Die Kovarianz zweier Nutzer wird durch deren Standardabweichung dividiert. Der Definitionsbereich ist auf Werte zwischen -1 und +1 beschränkt, wobei Paare mit hohem positivem Korrelationskoeffizienten als zueinander ähnlich gewertet werden.

Beispiel 1: Neighbourhood-Methode - Bestand der Bewertungsdaten (Schulnoten) der Nutzer und berechnete

Korrelationskoeffizienten (gerundet)

In diesem Beispiel wurden Nutzer1 und Nutzer4 als zueinander sehr ähnlich identifiziert (Korrelationskoeffizient = 0.97). Hier erscheint eine Empfehlung von Inhalt4 an Nutzer1 sinnvoll. Dagegen haben z.B. Nutzer3 und Nutzer4 so gut wie keine Gemeinsamkeiten (Korrelationskoeffizient = -0.65).

Modellbasiert (Model-based)

Im Gegensatz zum speicherbasierten Verfahren, wird bei modellbasierten Techniken nicht ständig auf den gesamten Datenbestand zurückgegriffen.

Stattdessen wird aus den Nutzerdaten ein Modell generiert (geschätzt, gelernt), wofür eine Reihe verschiedener Verfahren (Cluster Model, Gibbs Sampling, Clustered Pearson Algorithm, Bayesian Model, Bayesian Mixed Effects Model) Anwendung finden.

Ob speicher- oder modellbasiert - für den Einsatz kollaborativer Filtertechniken müssen zwei wichtige Vorraussetzungen erfüllt sein: Zum einen bedarf es einer umfangreichen Menge möglichst vielfältiger Inhalte. Zum anderen ist eine große bis sehr große Nutzerzahl zwingend erforderlich, um gute Ergebnisse zu erhalten.

Sind diese Vorraussetzungen erfüllt, stellt die Technik des kollaborativen Filterns ein sehr leistungsfähiges Verfahren dar und bringt eine Reihe von wesentlichen Vorteilen gegenüber den vorher genannten Verfahren:

• Die Kenntnis der Identität des Nutzers ist nicht erforderlich, da nur

• Jeder Nutzer kann individuell betrachtet werden.

• Durch Auswertung der Gruppenpräferenzen können dem Nutzer auch neue (ihm unbekannte) Inhalte vorgeschlagen werden.

• Es fällt kein hoher Initialaufwand an, da die zu personalisierenden Inhalte nicht klassifiziert werden müssen.

• Das System muss kaum manuell gepflegt werden, da es aus den

• Das System ist sehr flexibel einsetzbar.

Allerdings ist auch der Einsatz dieser Technik mit einer Reihe von Problemen verbunden:

• Nicht die Inhalte der Empfehlungen, sondern nur die Empfehlung

• Die Nichtberücksichtigung der Inhalte der Bewertungen birgt das Risiko irrelevanter Vorschläge durch zufällige Zusammenhänge.

• Nur mindestens einmal bewertete Inhalte werden durch das System

• Das System kann erst mit Erreichen einer bestimmten Anzahl von

• Für exotische Nutzerprofile werden schlechtere Empfehlungen

3. Konzepte zur Lösung

Das Konzept für eine Personalisierungslösung, das in dieser Arbeit vorgestellt werden soll, verfolgt einen nicht-integrativen und modularen Ansatz. Dies bedeutet nicht nur eine strikte Trennung von Personalisierungssystem und Anwendung. Auch das Personalisierungssystem selbst ist modular aufgebaut und gliedert sich in folgende Bestandteile:

• Datengewinnung

• Informationsgewinnung

• Wissensgewinnung

• Personalisierungstechniken

• Auswertung

Zentraler Bestandteil ist dabei die Datenbank, in der sämtliche Ein- und Ausgabedaten der einzelnen Verarbeitungsschritte abgelegt und verwaltet werden.

3.1 Datengewinnung

Verallgemeinert kann das Wort „Individualisierung“ als Anpassung einer Sache an ein Subjekt hinsichtlich seiner individuellen Merkmale verstanden werden. Naturgemäß erfordert dies die Kenntnis der individuellen Merkmale des Subjekts.

Bezogen auf die Anpassung der Schnittstelle eines Informationssystems für einen konkreten Nutzer bedeutet dies die Notwendigkeit der Kenntnis aller relevanten Daten zu den Eigenschaften dieses Nutzers, wie z.B. Interessen, Gewohnheiten, Vorlieben, Fähigkeiten, Lebensumständen usw. Die Komplexität und Treffsicherheit der Techniken zur Anpassung hängt dabei in hohem Maße von der Qualität der aus diesen Daten gewonnenen Informationen ab. Für die Qualität einer Information sind hierbei u.a. Kriterien wie Aktualität, Wahrheitsgehalt und Komplexität maßgeblich. All diese Anforderungen an die Qualität der Informationen machen die Datengewinnung zu einem wesentlichen Bestandteil eines Personalisierungssystems.

Herkömmliche Techniken / Fragebogen

Die einfachste und deshalb wohl verbreitetste Methode zur Gewinnung von Daten zu Merkmalen des Nutzers ist der klassische Fragebogen. Dem Nutzer wird hierbei (meist einmalig, bei Erstnutzung des Informationssystems) ein Katalog aus Fragen präsentiert. Das Spektrum dieser Fragen reicht dabei von den einfachen persönlichen Daten, wie Name und Alter, über eigene Interessen bzw. Vorlieben, bis hin zur charakterlichen Selbsteinschätzung. Hierbei muss die Sicherung der Qualität der Information allein dem Nutzer überlassen werden, was nicht unproblematisch ist. Menschen neigen dazu, Fragen zur eigenen Person nicht immer objektiv zu beantworten, was ihnen meist nicht einmal bewusst ist. Der Wahrheitsgehalt der so gewonnenen Informationen kann also nicht immer als gesichert angesehen werden.

Hinzu kommt, dass die Akzeptanz seitens der Nutzer gegenüber Fragebögen nur gering ist und mit steigender Anzahl der Fragen weiter abnimmt. Der Konflikt zwischen dem Wunsch, möglichst viele Daten über den Nutzer zu erfragen auf der einen Seite und der mangelnden Akzeptanz der Nutzer auf der anderen Seite, kann nur durch einen Kompromiss überwunden werden: Wenige einfache Fragen, bei deren Beantwortung der Nutzer nicht den Eindruck gewinnt, allzu viel über sich preisgeben zu müssen. Diese Technik ermöglicht Komplexitätsmaß Information. Ein weiterer wichtiger Aspekt ist die Aktualität der erfragten Daten. Nur zum Zeitpunkt der Beantwortung der Fragen können die Daten als wirklich aktuell angesehen werden. So können sich z.B. die Interessengebiete eines Nutzers mit der

Zeit ändern. Je mehr Zeit seit der Beantwortung vergangen ist, desto geringer ist das Aktualitätsmaß der Daten. Somit nimmt auch die Qualität der aus diesen Daten gewonnenen Information stetig ab. Um eine ausreichende Aktualität der Daten gewährleisten zu können, müsste die Nutzerbefragung also regelmäßig wiederholt werden, was wiederum auf starke Akzeptanzprobleme stoßen würde. Das also nur als gering einzuschätzende Qualitätsmaß der mit Hilfe eines Fragebogens gewonnenen Informationen lässt diese Methode nur für einfachste

17 Anmeldung GMX, http://www.gmx.de (abgerufen am 24 Januar 2002)

Personalisierungstechniken als geeignet erscheinen, z.B. für den Themenfilter eines Nachrichtenportals.

Kontinuierliche Nutzerbeobachtung

Die im vorangegangenen Abschnitt gezeigten Probleme im Zusammenhang mit der Datensammlung per Fragebogen gründen sich auf die direkte Inanspruchnahme des Nutzers, die mangelhafte Aktualität und die unzureichende Komplexität der mit diesem Verfahren gesammelten Daten und den daraus gewonnenen Informationen.

Eine Technik, die durch kontinuierliches Beobachten des Verhaltens des Nutzers Daten sammelt, könnte hier, zumindest teilweise, Abhilfe schaffen. Die so gesammelten Daten wären ständig ausreichend aktuell - und das, ohne den Nutzer direkt in Anspruch nehmen zu müssen. So entfiele also auch das Problem undifferenzierter bzw. unrichtiger Angaben des Nutzers. Im Folgenden soll nun untersucht werden, inwieweit und unter welchen technischen Vorraussetzungen die Datengewinnung durch eine kontinuierliche Nutzerbeobachtung realisierbar ist.

3.1.1 Technischer Ansatz zur kontinuierlichen

Nutzerbeobachtung

Beobachtet werden soll das Verhalten des Nutzers, d.h. alle seine Aktionen, wie Navigation, Eingaben (z.B. Suchanfragen) usw. Die Grundlage solcher Aktionen ist in der Regel die Anforderung einer Inhaltsseite beim Webserver. Entscheidet sich der Nutzer beispielsweise durch Klick auf einen Link für einen bestimmten Beitrag im Angebot eines Nachrichtenportals, so löst dies eine Seitenanforderung beim Server aus.

Da Seitenanforderungen aus technischen Gründen die einzige Möglichkeit zum Austausch von Informationen zwischen Client und Server sind, muss es auch genügen, diesen Vorgang zu beobachten, um alle relevanten Daten zu erhalten. Bei einem seitenbasierten Informationssystem, wobei jede klassische Website als ein solches System angesehen werden kann, bedeutet “Nutzerbeobachtung„ also allein die Analyse des Musters der durch den Nutzer ausgelösten Anforderungen von einzelnen Inhaltsseiten und den dabei übermittelten Daten.

Das Datensammler-Modul ist als automatisch arbeitendes System zu verstehen, welches die im Webserver eingehenden Seitenanforderungen registriert und auswertet. Dazu gehört die Analyse der angeforderten URL (mit Parametern), sowie die Untersuchung des Inhaltes der angeforderten Seite. Alle gewonnenen relevanten Daten müssen anschließend in einer für eine spätere Auswertung geeigneten Form abgespeichert werden. Im Rahmen dieser Diplomarbeit wurde der Prototyp eines solchen Apache ¹⁸ -Modul Datensammler-Moduls als unter Verwendung der

Servererweiterung ModPerl ¹⁹ realisiert.

¹⁸ siehe auch http://www.apache.org/

¹⁹ siehe auch http://perl.apache.org/

3.1.2 Beschreibung der Funktionsweise

Da die Auswertung der Seitenanforderungen aus Performancegründen nicht in Echtzeit, also unmittelbar zum Zeitpunkt der Anforderung, erfolgen kann, müssen zunächst alle relevanten Daten dieser Anforderungen (z.B. URL, URL-Parameter, Post/Put-Daten) protokolliert und damit dauerhaft erfasst werden. Dazu sind eine Reihe von Schritten notwendig.

3.1.2.1 Identifikation der Session bzw. des Nutzers

Den ersten Schritt stellt die Identifikation der Session bzw. des Nutzers dar. Um aus gesammelten Daten Informationen über einen Nutzer zu gewinnen, müssen diese Daten dem Nutzer natürlich auch eindeutig zugeordnet werden können. Für die technische Realisierung sind im Wesentlichen zwei Methoden denk- und realisierbar:

Automatische Variante

Für den Fall, dass das zu personalisierende System über keine eigene Nutzerverwaltung verfügt, muss die Aufgabe der Nutzeridentifikation ebenfalls durch das Datensammler-Modul übernommen werden. Hierzu wird zu Beginn jeder Session automatisch eine eindeutige SessionID erzeugt und per Cookie clientseitig hinterlegt. So können durch Auslesen des Cookies auch spätere Sessions dem Nutzer eindeutig zugeordnet werden. Dieses Verfahren bringt aber zwei wichtige Probleme mit sich:

Mit der Cookie-Methode wird tatsächlich nur der Client-Computer identifiziert - nicht der Nutzer selbst. Benutzen nun mehrere Personen denselben Computer (ohne spezielle Nutzerprofile), so können diese nicht unterschieden werden, was eine Verfälschung der gewonnenen Informationen bedeuten würde. Jedoch sind mittlerweile Betriebssysteme mit integrierter Nutzerprofilverwaltung zum Standard geworden, was den Stellenwert dieser Problematik mindert.

Das zweite, noch wichtigere, Problem dieser Methode stellt die mögliche Deaktivierung der Cookie-Funktion des Browsers durch den Nutzer dar. In einem solchen Fall könnten keine Informationen clientseitig gespeichert werden, was eine automatische Nutzeridentifikation unmöglich machen würde. Allerdings setzen heutzutage vielen Websites die Nutzbarkeit der Cookie-Funktion voraus, was somit zumindest in diesen Fällen auch den Einsatz der automatischen Nutzeridentifikation ermöglicht. Es hat also durchaus Sinn, diese Methode der Nutzeridentifikation zu implementieren.

Nutzung der systemeigenen Nutzeridentifikation

Verfügt das zu personalisierende System bereits über eine eigene Nutzerverwaltung, so liegt es natürlich nahe, diese auch für das Datensammler-Modul nutzbar zu machen. Im einfachsten Fall wird der Nutzeridentifikator bereits durch das Informationssystem bei jeder Seitenanforderung mitgeführt und steht somit auch dem Datensammler-Modul jederzeit zur Verfügung. Der Betreiber muss dazu den Parameter spezifizieren, welcher den Nutzer identifiziert.

Oft wird jedoch aus Sicherheitsgründen nicht der Nutzeridentifikator selbst mitgeführt, sondern nur ein Sessionidentifikator, welcher meist zu Beginn jeder Session als Zufallszahl neu erzeugt und in einer gesonderten Datenbanktabelle dem eigentlichen Nutzeridentifikator zugeordnet wird. Da das Datensammler-Modul mit dem Sessionidentifikator allein den Nutzer nicht identifizieren kann, müssen in diesem Fall durch den Betreiber geeignete Maßnahmen getroffen werden. Beispielsweise wäre es möglich, zusätzlich zum Sessionidentifikator auch den Nutzeridentifikator als URL-Parameter mitzuführen. Die Sicherheit bliebe dabei gewährleistet, da das Informationssystem nicht den zusätzlich mitgeführten Nutzeridentifikator, sondern allein den Sessionidentifikator zur Erkennung des Nutzers verwendet. Alternativ dazu kann vom Betreiber der Identifikator bereits im Quelltext integriert werden, der vom Personalisierungssystem ausgewertet wird.

Für beide Methoden müssen natürlich auch die üblichen Sicherheitsmaßnahmen zum Schutz vor Manipulationen implementiert werden. So darf es z.B. Nutzern nicht möglich sein, durch Veränderung der nutzeridentifizierenden URL-Parameter Schaden anzurichten.

3.1.2.2 Identifikation der angeforderten Seite

Der nächste Schritt ist die Identifikation der angeforderten Inhaltsseite. Nur durch eine eindeutige Identifikation ist es möglich, Aktionen des Nutzers Inhaltsseiten zuzuordnen. Jede Inhaltsseite muss also durch einen ihr zugeordneten Bezeichner repräsentiert werden. Hierfür sind im Wesentlichen zwei verschiedene Ansätze denkbar - zum einen eine automatische und zum anderen eine explizite Benennung der Inhaltsseiten, wobei letztere durch den Betreiber vorgenommen werden müsste.

Automatische Variante

Um eine Inhaltsseite sicher automatisch zu benennen, müssen Techniken gefunden werden, die unter Einbeziehung gewisser Merkmale der Seite einen Bezeichner generieren, welcher eindeutig und reproduzierbar ist. Jede Inhaltsseite muss also ihrem Bezeichner zugeordnet werden können und umgekehrt.

Bei rein HTML-basierten Websites ist dies meist trivial. Hierbei wird jede Inhaltsseite durch eine HTML-Datei repräsentiert. Als Seitenidentifikator kann also der Name dieser HTML-Datei dienen.

URL: /support/faq.html Bezeichner: /support/faq.html

Beispiel 2: Einer statischen HTML-Datei kann ihre URL als Bezeichner zugeordnet werden

Anders bei skriptbasierten Websites. Hier werden die eigentlichen Inhaltsseiten dynamisch mit Hilfe von Skripten (z.B. Perl, PHP, ColdFusion usw.) erzeugt, wobei keine direkte eindeutige Zuordnung von erzeugter Inhaltsseite zur zuständigen Skript-Datei möglich ist. So kann ein Skript durchaus für die Generierung von mehreren verschiedenen Inhaltsseiten verantwortlich seinabhängig z.B. von übermittelten Parametern (URL-/Submit-Parameter). Selbst ein Portal mit mehreren hundert einzelnen Inhaltsseiten wird oft nur mit einigen wenigen Skripten realisiert. Erst die Kombination des Skript-Dateinamens mit der zugehörigen Menge von Parametern ergibt eine Einheit, die als Seitenidentifikator genutzt werden kann.

Zunächst müssen also sämtliche übertragenen Parameter in Erfahrung gebracht werden. Es existieren zwei etablierte Methoden der

Parameterübermittlung. Die gängigste dabei ist das direkte Anhängen der Parameter an die URL, abgesondert durch ein Fragezeichen. Die Parameter selbst sind in der Form Bezeichner=Wert notiert und durch das Zeichen & voneinander getrennt. Die zweite wichtige Methode ist die Übermittlung von Daten unter Verwendung von Formularen. Hierbei werden die Daten nicht als URL-Anhang übertragen, sondern in einem gesonderten Puffer, der vom Server ausgelesen werden kann. Beide Methoden in Kombination sind die Basis der Datenübertragungen per HTTP-Protokoll auf denen heutige Websites aufbauen. Aus dem URL-Pfad und den verfügbaren Parametern lässt sich nun eine Zeichenkette generieren. Jeder so erzeugte Bezeichner kann einer Inhaltsseite zugeordnet werden und umgekehrt.

URL+Parameter: /cgi-bin/forum.pl?fid=2&uid=76&pid=339 Bezeichner:

/cgi-bin/forum.pl?fid=2&uid=76&pid=339

Beispiel 3: Einer skript-generierten Seite kann eine aus der URL und den übermittelten Parametern (URL-/Post-

Parameter) gebildete Zeichenkette als Bezeichner zugeordnet werden

Einschränkend muss ergänzt werden, dass eine Eindeutigkeit nicht garantiert werden kann, da skriptbasierte Systeme auch an innere Zustände gebunden sein können. Im Falle der Änderung eines solchen inneren Zustandes können auch bei völlig identischen URLs durchaus unterschiedliche Ausgaben erzeugt werden. Dies kann z.B. durch die Einbeziehung von Daten verursacht werden, die im Dateisystem oder einer Datenbank abgelegt wurden. Als Beispiel sei auf eine Gültigkeitsprüfung verwiesen, die nur dann zu einer Erfolgsseite verzweigt, wenn eine Kombination von Name und Passwort als gültig identifiziert wurde. Da die für die Prüfung verwendeten Daten aus einer Datenbank ausgelesen wurden, kann anhand der URL kein eindeutiger Seitenidentifikator bestimmt werden.

In diesen Fällen kann vom Betreiber der Website mit Hilfe der vom Personalisierungssystem zur Verfügung gestellten Metasprache explizit ein eindeutiger Seitenidentifikator in den HTML-Quelltext der Seite integriert werden.

Explizite Variante

Wie im vorherigen Abschnitt gezeigt, ist eine explizite Benennung von Inhaltsseiten durch den Betreiber immer dann sinnvoll, wenn eine automatische Benennung keinen eindeutigen Bezeichner generieren kann (z.B. wegen innerer Zustandswechsel).

Dem Betreiber muss also die Möglichkeit gegeben werden, explizit eine Benennung der entsprechenden Inhaltsseiten vorzunehmen. Dies könnte z.B. durch Verwendung der Metasprache realisiert werden.

…

…

…

Beispiel 4: Explizite Vergabe eines Seitenbezeichners mit Hilfe von Quelltextparametern

3.1.2.3 Identifikation der Aktionselemente

Analog zur Identifikation der Session/des Nutzers und der angeforderten Seite muss nun auch noch jedes Aktionselement der Seite identifiziert werden. Als Aktionselemente zu verstehen sind hier Links (...) sowie Formulare (...). Auch hier ist wieder sowohl eine automatische als auch eine explizite Variante denkbar und sinnvoll.

Automatische Variante

Zur eindeutigen Benennung eines Links kann aus dem URL-Verweis sowie der durch das öffnende und schließende Link-Tag begrenzten Zeichenkette (u.U. auch HTML-Quelltext), ein Bezeichner gebildet werden. Link-Tag:

QWERTY Bezeichner: http://www.blickreich.de_QWERTY

Beispiel 5: Bildung des Bezeichners eines Aktionselementes (Link) aus der Ziel-URL und dem Link-Text

Auf ähnliche Weise ist dies auch für Formulare möglich. Der Bezeichner kann hier aus dem Attributbereich des Form-Tags und den Namen der einzelnen Formularfelder gebildet werden. Formular:

/cgi-bin/dynamic.pl_KommentarKundennummerPasswortAbsenden

Beispiel 6: Für ein Formular kann der Bezeichner aus dem Attributbereich und den Namen der Fomularfelder

gebildet werden.

Um Mehrdeutigkeiten mit sonst identischen Aktionselementen auf anderen Inhaltsseiten auszuschließen, muss auch der Seitenidentifikator bzw. die PageID in den Bezeichner für Aktionselemente integriert werden. Für den (sehr unwahrscheinlichen) Fall, dass nach dieser Vorschrift für zwei Aktionselemente auf derselben Seite ein identischer Bezeichner gebildet wird, genügt es, an vergebene Bezeichner eine fortlaufende Nummerierung anzufügen.

Eindeutiger Bezeichner: http://www.blickreich.de_QWERTY_114_1

Beispiel 7: Anhängen des Seitenindentifikators und einer fortlaufenden Nummerierung ermöglicht eindeutige

Vergabe von Aktionselement-Bezeichnern

Der so generierte Bezeichner erlaubt die eindeutige Identifikation jedes Aktionselementes jeder einzelnen Inhaltsseite und somit die Zuordnung jeder Aktion eines Nutzers zu einem Aktionselement und der zugehörigen Inhaltsseite.

Explizite Variante

Bei Einsatz des automatische Verfahrens zur Benennung von Aktionselementen wird jedes Aktionselement aller Inhaltsseiten als einmalig identifiziert. Dies ist aber nicht immer sinnvoll. Beispielsweise hat es Sinn, die einzelnen Punkte eines Seiten-Menüs, welches auf mehreren Inhaltsseiten identisch erscheint, auch seitenübergreifend zu identifizieren. Es soll also nicht für jeden Menüpunkt auf jeder Inhaltsseite ein neuer eindeutiger Bezeichner gebildet werden. Vielmehr ist jeder Menüpunkt, der auf mehreren Inhaltsseiten erscheint, als funktionale Einheit zu sehen. Solche funktionalen Einheiten müssen durch den Betreiber explizit definiert und somit benannt werden können.

Ähnlich wie für die explizite Benennung von Inhaltsseiten kann auch hier vorgegangen werden. Dem Betreiber müssten hierzu mit Hilfe von Elementen der Metasprache geeignete Verfahren zur Verfügung gestellt werden. Es bedarf also der Möglichkeit einer sinnvollen Kombination von automatischer und expliziter Benennung von Aktionselementen. Sinnvoll könnte hier z.B. bedeuten, einer expliziten Benennung eines Aktionselementes stets Vorrang zu gegeben, sodass die automatische Benennung nur bei Nicht-vorhandensein einer expliziten Benennung zum Einsatz gebracht wird. Die explizite Benennung eines Aktionselementes könnte z.B. wie folgt geschehen: Link-Tag:

QWERTY

Beispiel 8: Explizite Vergabe eines Bezeichners für ein Aktionselement durch den Betreiber

Der Wert des Name-Attributs (“link1”) stellt dabei den explizit vergebenen Bezeichner dar. Hierbei muss es natürlich dem Betreiber überlassen werden, auf Konsistenz und Eindeutigkeit der Bezeichner zu achten. Auch die weiter oben angesprochenen funktionalen Einheiten ließen sich so durch eine Mehrfachvergabe desselben Bezeichners definieren. Stünde der

Link aus obigem Beispiel in dieser Form in mehreren verschiedenen Inhaltsseiten, so würde er dank seiner expliziten Benennung immer als ein und dasselbe Aktionselement identifiziert. Gleiches gilt natürlich auch für Formulare. Eine weitergehende Möglichkeit zur Benennung von Aktionselementen ist die Bildung von funktionalen Einheiten, bestehend aus verschiedenen Aktionselementen einer Inhaltsseite. Eine solche Gruppierung ist immer dann sinnvoll, wenn mehrere Aktionselemente logisch einer Funktionsgruppe zuzuordnen sind. Beispielsweise stellt eine „Weiter/Zurück“-Navigation einen solchen Fall dar (siehe Beispiel 9: Definition einer funktionalen Einheit, bestehend aus mehreren Aktionselementen). Für eine Personalisierung hat hier nur die gemeinsame Betrachtung der Schaltflächen „Zurück“ und „Weiter“ Sinn, d.h. beide Links müssen als ein Aktionselement identifiziert und benannt werden. Dies könnte z.B. durch Implementierung geeigneter metasprachlicher Konstrukte realisiert werden: < Zurück | Weiter >

&lt;&nbsp;

Zurück

&nbsp;|&nbsp;

Weiter

&nbsp;&gt;

Beispiel 9: Definition einer funktionalen Einheit, bestehend aus mehreren Aktionselementen

Das Kommentar-Tag „qwertyBlock“ übernimmt hier die Definition der funktionalen Einheit. Alle in diesem Block eingeschlossenen Links bzw. Formulare werden nicht länger einzeln benannt, sondern erhalten als Ganzes den Bezeichner „PageFlicker“. Das Beispiel zeigt auch, dass es nun möglich ist, nicht nur Links in eine solche Gruppe einzuschließen, sondern auch anderen zugehörigen HTML-Quelltext (hier z.B. „<“,“|“,“>“).

Nun lassen sich durch Mehrfachvergabe von Gruppenbezeichnern sogar seitenübergreifende funktionale Einheiten bilden. Die explizite Vergabe von Bezeichnern ermöglicht auch, bewusst bestimmte Aktionselemente bzw. Funktionseinheiten von der Identifikation und somit von der Personalisierung auszuschließen. Z.B. könnte dies für Sprungmarken innerhalb einer Inhaltsseite sinnvoll sein.

nach open

…

Beispiel 10: Ausschluss eines Links durch Definition eines unbenannten Blocks

Die Kennzeichnung, dass dieser Sprungmarken-Link ignoriert werden soll, erfolgt hier durch den Einschluss des Links in einen „qwertyBlock“, der keinen expliziten Bezeichner besitzt.

3.1.2.4 Identifikation aktiver Textdaten

Ein Personalisierungssystem sollte es erlauben, textuelle Eingaben in das Profil eines Nutzers einfließen zu lassen.

Um dies zu realisieren, muss zunächst erkannt werden, ob es sich bei den jeweiligen übermittelten Eingabeparametern um vom Nutzer eingegebene Einträge handelt oder nicht. Es muss dabei beachtet werden, dass das Personalisierungssystem nur eine URL-Anforderung erhält, in der die entsprechenden Nutzereingaben als Parameter oder im HTTP-Request enthalten sind. Eine einfache Unterscheidung, ob es sich um textuelle oder numerische Einträge handelt, reicht natürlich nicht aus. Anhand einiger Beispiele soll im Folgenden auf die Probleme bei der Erkennung von Nutzereinträgen hingewiesen werden.

Beispiel 12: HTML-Formular mit Nutzereingabe

Es handelt sich hierbei um ein gewöhnliches HTML-Formular. Nach einem Klick auf den Absenden-Button wird vom Client, auf dem dieses HTML-Formular dargestellt wurde, ein HTTP-Request-Objekt erzeugt, in welchem auch die Eingabeelemente des Formulars enthalten sind: WarenkorbID = "347hifu472"

Extra = "Oliven, Speck"

Kommentar = [Eingabe des Nutzers]

Kundennummer = [Eingabe des Nutzers]

Passwort = [Eingabe des Nutzers]

Beispiel 13: Parameterübermittlung durch CGI-Datenübertragung

Das Personalisierungssystem hat an dieser Stelle keine Möglichkeit mehr zu erkennen, dass es sich bei WarenkorbID und Extra nicht um aktive Nutzereingaben handelt, im Gegensatz zu Kommentar, Kundennummer und Passwort. Des Weiteren kann man feststellen, dass in bestimmten Eingabefeldern zwar aktive Texteingaben erfolgen, aber möglicherweise keine

sinnvollen Daten in Bezug auf ein Nutzerprofil zu erwarten sind. So hat es beispielsweise keinen Sinn, die Kundennummer in eine Personalisierung des Nutzerwortschatzes mit einzubeziehen. Ein weiterer Punkt wird am beschriebenen Fall deutlich. Einige Felder sollten aus Sicherheitsgründen nicht ausgewertet werden. Dies betrifft hier das Passwort-Feld. Anhand der Aufzählungen lässt sich erkennen, dass es notwendig ist, auszuwertende Eingabefelder explizit zu bestimmen. Der Betreiber muss die Möglichkeit erhalten, die Eingabefelder zu spezifizieren, auf die er Personalisierungstechniken anwenden möchte. Dies kann mit Hilfe der Metasprache erreicht werden, z.B. durch Verwendung eines Attributs, welches dem entsprechenden HTML-Input-Tag hinzugefügt wird: Alternativ ist dies auch durch einen umschließenden Kommentarblock realisierbar, da nicht alle visuellen HTML-Editoren das Einfügen beliebiger Attribute erlauben:

Wie wir feststellen konnten, erhält das Personalisierungssystem die Formulardaten über das HTTP-Protokoll in Form eines Requests. Um nun herauszufinden, welche übermittelten Argumente auszuwerten sind, müsste die Ausgangsseite erneut geladen und der Quelltext nach den oben beschriebenen Metasprachelementen durchsucht werden. Dies stellt keine sonderlich ökonomische Variante dar. Deshalb wird bereits beim Schritt zuvor, nämlich bei der Anforderung der Seite, die das Formular enthält, diese Analyse vorgenommen. Da jede Seite ohnehin einmal geparst werden muss, stellt es keine Zusatzlast mehr dar. Dem Formular wird nun in diesem Schritt bereits ein weiteres „hidden“-Feld hinzugefügt, welches Informationen über die auszuwertenden Formular-Felder enthält. Mit Hilfe dieses „hidden“-Felds können schließlich vom Personalisierungssystem die entsprechenden Eingabefelder als aktive textuelle Daten behandelt und zur

Informationsverarbeitung an das zuständige Linguistik-Modul weitergereicht werden. Dies geschieht über die Schnittstelle zwischen Datengewinnungs- und Informationsgewinnungsschicht.

Eine genaue technische Betrachtung zeigt, dass es nicht notwendig ist, die kompletten textuellen Daten abzulegen. Da die Textdaten bereits bei der Protokollierung der Nutzeraktionen und der dabei gespeicherten Parameter-Werte-Paare in der Datenbank aufgenommen werden, ist es ausreichend, nur die Parameter-Bezeichner in einer separaten Tabelle für die Protokollierung der Textdaten abzulegen. Es wäre prinzipiell auch denkbar, diese Parameter-Bezeichner direkt in die Tabelle, welche für die Protokollierung der Nutzeraktionen zuständig ist, zu speichern. Jedoch muss man bedenken, dass es sich bei dem überwiegenden Teil von Nutzeraktionen um Navigationen handelt, nicht um textuelle Eingaben. Eine seperate Speicherung ist demzufolge wesentlich ökonomischer.

Folgendes Beispiel zeigt die Verwendung des Attributes „qwertyUse“ zur expliziten Kennzeichnung der zu verarbeitenden Formularfelder durch den Betreiber. Es wurde ein zusätzliches verstecktes Feld eingefügt, welches die Bezeichner aller mit „qwertyUse“ gekennzeichneten Formularfelder enthält:

Beispiel 14: Spezifikation zu verarbeitender Eingabefelder

3.1.2.5 Identifikation passiver Textdaten

Im letzten Abschnitt wurde diskutiert, wie aktive Eingaben der Nutzer erkannt und als Daten für die Informationsgewinnung bereitgestellt werden können. Aktive Eingaben des Nutzers haben einen direkten Bezug zu dessen

persönlichem Profil. Deshalb sind diese Daten besonders interessant für eine Personalisierung.

Abhängig von der konkreten Anwendung sind Eingaben jedoch im Verhältnis zu anderen Aktionen der Nutzer, etwa der Navigation, relativ selten. Wesentlich häufiger ist der Nutzer passiv, indem er z.B. Seiteninhalte liest. Auch dies sagt etwas über die Eigenschaften des Nutzers aus, z.B. über thematische Interessen bezüglich des gelesenen Textes.

Im Zusammenhang mit der Navigation ist es daher sinnvoll, auch diese passiven Textdaten zu betrachten. Bei passiven Textdaten handelt es sich demnach um Texte, welche nicht vom Nutzer, sondern von der Anwendung bereitgestellt werden. Natürlichsprachliche Inhalte einer Seite, die vom Nutzer gelesen wurde, gehören dazu - idealerweise nur wirklich relevante Inhalte.

Damit haben wir jedoch zugleich weitere Fragen aufgeworfen. Was sind relevante Inhalte und welche Seiten wurden vom Nutzer tatsächlich gelesen? Dies sind Probleme, welche auf der Ebene der Datengewinnung keine Betrachtung finden können. Dazu müssen zunächst Navigationsdaten und Textdaten analysiert werden, was jedoch erst auf der Informations-Ebene geschieht. Aufgabe des Datengewinnungsmodules ist es lediglich, die Daten möglichst verlustfrei bereitzustellen, die bei der Informationsverarbeitung genutzt werden können.

Im Fall der passiven Textdaten bedeutet eine verlustfreie Bereitstellung, dass der gesamte Quelltext einer Seite gespeichert werden muss, bis er auf Informationsebene verarbeitet wurde. Genauer betrachtet entspricht dies der Speicherung der aktuellen Seite eines jeden aktiven Nutzers, welche bei einem erneuten Seitenaufruf überschrieben werden kann, da dann die Informationsverarbeitung bereits stattgefunden hat.

3.1.2.6 Protokollierung der Seitenanforderung

Um eine spätere Auswertung zu ermöglichen, müssen nun alle relevanten Daten der Anforderung in geeigneter Form abgelegt werden, wofür nur eine leistungsfähige Datenbank in Frage kommen dürfte. Diese Datenbank enthält dann im Wesentlichen zwei Arten von Daten: Daten zu referenzierten Objekten (Seiten, Links) sowie dem Protokoll, welches die Seitenanforderungen in chronologischer Ordnung enthält.

Tabelle Pages

Die Einträge in dieser Tabelle repräsentieren die eindeutig identifizierten Seiten, auf die in mindestens einer protokollierten Seitenanforderung Bezug genommen wurde. Bei jeder Seitenanforderung muss also zunächst geprüft werden, ob bereits eine Seite mit diesem Bezeichner in Pages existiert. Ist dies der Fall, so wurde diese Seite zu einem früheren Zeitpunkt schon einmal angefordert, d.h. es kann auf den bestehenden Eintrag referenziert werden. Enthält Pages noch keinen Eintrag für diesen Bezeichner, so stellt dies eine erstmalige Anforderung dieser Seite dar, d.h. es muss ein neuer Eintrag in Pages erzeugt und dann auf diesen referenziert werden. Mit Hilfe dieser Methode lassen sich später Aktionen eines oder mehrerer Nutzer in direkten Bezug zu einer Seite stellen.

Tabelle Links

Analog zur Tabelle Seiten repräsentieren die Einträge der Tabelle Links sämtliche eindeutig identifizierten Links, die in allen angeforderten Seiten enthalten waren. Auch hier muss der Bezeichner jedes identifizierten Links zunächst auf Existenz in Links geprüft, ggf. eingetragen und dann referenziert werden.

Tabelle Protocol

Alle Einträge in diese Tabelle repräsentieren Seitenanforderungen. Zu jeder Anforderung werden die ID der Ursprungsseite, die ID des verwendeten Links, die ID der angeforderten Seite, die Session- bzw. Nutzer-ID sowie Datum und Uhrzeit gespeichert.

Tabelle User

Die Tabelle User erfüllt mehrere Aufgaben. Primär ist sie für die Sessionverwaltung, also für die Zuordnung von SessionIDs und NutzerIDs verantwortlich. Das Feld PageCache nimmt bei jeder neuen Seitenanforderung den Quelltext dieser Seite auf. Dies ist für die Auswertung des Seiteninhaltes wichtig, der erst mit der nächsten Seitenanforderung vorgenommen werden kann. Zusätzlich macht das Caching der angeforderten Seiten auch das Echtzeit-Monitoring der Nutzeraktionen möglich.

Tabelle Inputs

In dieser Tabelle werden alle textuellen Eingaben der Nutzer abgelegt. Dabei werden der Name des Formulars sowie der Feldname und Feldwert des jeweiligen Eingabefeldes referenziert. Gemeinsam mit dem Eintrag ProtocolID wird somit eine eindeutige Referenz zu der Datenquelle gespeichert.

3.1.2.7 Modifikation des HTML-Quelltextes

Um eine spätere genaue Rekonstruktion der Navigationswege zu ermöglichen, ist es notwendig, dass durch das Datensammler-Modul gewisse Informationen im Quelltext der angeforderten Seite hinterlegt werden, die es ermöglichen, diese Seite mit der nächsten durch den Nutzer angeforderten Seite in Beziehung zu setzen. Das heißt nichts anderes, als dass jeder Seitenanforderung die Ursprungsseite, also die Seite, die den zur Anforderung verwendeten Link enthält, zugeordnet werden kann. Mit jeder Seitenanforderung, müssen also die PageID der Ursprungsseite und die LinkID des verwendeten Links bzw. Formulars mit übermittelt werden. Bei normalen Links ist dies durch Anhängen der IDs als Parameter an die URL des href-Attributes realisierbar:

srclinkid=114&sessionid=18377563”>...

Beispiel 16: Übermittlung von Ursprungsseiten-, Link- und Session-Indentifikator als URL-Parameter

Anders bei Formularen. Da hier ein Anhängen der Parameter an die action-URL nicht möglich ist, muss für jeden Parameter ein verstecktes Formularfeld in das Formular eingefügt werden, was in der Regel keine Probleme verursachen sollte, da solche Formularfelder keinerlei Einfluss auf Layout und Funktion der Inhaltsseite haben.

Beispiel 17: Übermittlung von Ursprungsseiten-, Link- und Session-Indentifikator als versteckte Formularfelder

Wie in obigem Beispiel zu sehen, kann neben den IDs für Ursprungsseite und verwendeten Link auf gleichem Weg auch die ID der Session übermittelt

werden. Insgesamt werden also mit jeder Seitenanforderung drei Parameter an das Datensammler-Modul übermittelt.

3.2 Informationsgewinnung

Wie der Name bereits sagt, hat das Datensammler-Modul allein die Aufgabe, alle nur möglichen relevanten Daten zu Seitenanforderungen zu sammeln und zu protokollieren. Diese Daten allein ermöglichen allerdings noch nicht den Einsatz von Personalisierungstechniken. Der gesammelte Datenbestand besteht nur aus einem chronologisch geordneten Protokoll aller Seitenanforderungen und der durch dessen Einträge referenzierten Objekte (Seiten, Aktionselemente, Sessions/Nutzer). Diese große Menge von Daten muss also zunächst weiterverarbeitet werden, um aus ihr so viel Information wie möglich zu gewinnen. Wie wir später sehen werden, handelt es sich dabei nicht nur um Informationen zu den Nutzern und deren Verhalten. Vielmehr erlauben die gewonnenen Informationen zusätzlich auch Rückschlüsse zu Eigenschaften des Informationssystems selbst.

Die durch das Datensammler-Modul bereitgestellten Daten lassen sich im Wesentlichen in zwei Arten gliedern: Navigationsdaten und Inhaltsdaten. Unter Navigationsdaten sind hier die Daten aller durch Nutzer verursachten Seitenanforderungen zu verstehen. Inhaltsdaten hingegen stellen die durch die Analyse der Seiteninhalte und der bei den Seitenanforderungen übermittelten Parameter gewonnenen Daten dar.

3.2.1 Informationsgewinnung aus Aktionsdaten

Der Hauptanteil der durch das Datensammler-Modul bereitgestellten Daten bezieht sich direkt auf die Aktionen des Nutzers.

3.2.1.1 Aktionen

Wie oben erwähnt repräsentiert der Bestand der gesammelten Daten im Wesentlichen die Aktionen des Nutzers, z.B. Klicks auf Links oder das Absenden

von Formularen. Aus diesen Daten lassen sich vielerlei Informationen über das Verhalten des Nutzers gewinnen. Die aus diesen Daten direkt gewonnenen Informationen bilden dabei die unterste Komplexitätsstufe.

Häufigkeit und Intensität der Nutzung

Eine grundlegende Information, die sich aus Aktionsdaten gewinnen lässt, ist die Häufigkeit der Nutzung eines Aktionselementes durch den Nutzer. Dieser Wert liegt zwischen Null und einer beliebig großen Zahl. Er erlaubt indirekt die Beurteilung der Relevanz dieses Aktionselementes für den Nutzer. Für eine direkte Beurteilung kann die Nutzungshäufigkeit eines Aktionselementes nur ins Verhältnis zur durchschnittlichen Nutzungshäufigkeit aller anderen Aktionselemente bzw. der Häufigkeit des meistgenutzten Aktionselementes gesetzt werden. Der so gewonnene Wert - die Nutzungsintensität - steht für den Grad des Umfanges der Nutzung des Aktionselementes durch den Nutzer.

Für folgendes Beispiel wurde anhand der Nutzungshäufigkeit von zehn Aktionselementen deren Nutzungsintensität bestimmt.

Beispiel 18: Nutzungshäufigkeit und -intensität von zehn Aktionselementen

Eine Nutzungsintensität von 1 bezeichnet eine durchschnittliche Nutzungshäufigkeit. Werte größer bzw. kleiner als 1 bezeichnen eine über- bzw. unterdurchschnittliche Nutzungshäufigkeit.

3.2.1.2 Seitenwechsel

Die im vorherigen Abschnitt besprochenen Aktionsdaten lassen sich im Regelfall auch als Seitenanforderungen interpretieren, da die meisten der Nutzeraktionen nichts anderes als Klicks auf Links oder auch das Absenden von Formularen darstellen.

Jede neue durch eine Nutzeraktion ausgelöste Seitenanforderung kann bildlich als Ortswechsel dieses Nutzers angesehen werden - vorrausgesetzt, es wurde wirklich eine neue Seite angefordert und nicht die aktuelle Seite ein zweites Mal angefordert.

Häufigkeit und Intensität

Analog zur Häufigkeit und Intensität der Nutzung von Aktionselementen lassen sich diese Werte auch für Seitenanforderungen berechnen. Die Häufigkeit stellt hier die Anzahl der Aufrufe einer bestimmten Inhaltsseite (die Zielseite des Seitenwechsels) dar. Auch die Aufrufintensität lässt sich analog zur Nutzungsintensität von Aktionselementen bestimmen.

3.2.1.3 Navigationswege

Nicht jeder Link und die damit verbundene Seitenanforderung führt den Nutzer zu den gewünschten Inhalten. Oft bedarf es der Nutzung einer Reihe von Links, die ihn durch die verschiedenen Hierarchieebenen des Informationssystems führen, bis er schließlich zur gewünschten Inhaltsseite gelangt. Die auf diesem Weg aufgerufenen Seiten interessieren den Nutzer dabei oft nur insofern, als dass sie den Link zur nächsten Seite des Navigationsweges enthalten. Die Analyse dieser Navigationswege erlaubt

Rückschlüsse auf eine Vielzahl von Eigenschaften des Nutzers sowie des Informationssystems selbst.

Der erfasste Datenbestand erlaubt die Rekonstruktion des Weges, auf dem sich ein Nutzer durch die Seitentopologie des Informationssystems bewegt hat, d.h. wann und in welcher Reihenfolge er, mit Hilfe welcher Links, von einer Seite aus eine andere aufgerufen hat. Eine Nutzungssession besteht in der Regel aus mehreren solcher Standortwechsel.

Ein Navigationsweg sei also definiert als eine zusammenhängende Kette von Standortwechseln, beginnend mit einer Startseite und endend mit einer Zielseite. Um einen Navigationsweg zu identifizieren, muss nun zunächst geklärt werden, was unter einer Start- bzw. Zielseite zu verstehen ist, d.h. was diese von anderen Seiten unterscheidet.

Die Startseite bildet den Ausgangspunkt eines Navigationsweges. Diese kann entweder die erste innerhalb der Session angeforderte Inhaltsseite des Informationssystems oder die „ehemalige“ Zielseite des zuvor zurückgelegten Navigationsweges sein. Die Behandlung des ersten Falles ist trivial, da sich der erste Seitenaufruf innerhalb einer Session direkt aus dem Datenbestand ermittelt lässt. Für die Behandlung des zweiten Falles genügt die Definition des Begriffes „Zielseite“.

Die Zielseite eines Navigationsweges bildet den Endpunkt der Kette von Seitenanforderungen, die der Nutzer auf dem Weg zu den von ihm gewünschten Inhalten ausgelöst hat, d.h. die Zielseite enthält diese gewünschten Inhalte. Natürlich lässt sich nicht direkt ermitteln, um welche Inhalte es sich dabei handelte. Allerdings kann die Verweildauer eines Nutzers auf einer Seite ermittelt werden, indem die Differenz der Zeitpunkte des Aufrufes dieser und des der nächsten Inhaltsseite berechnet wird. Nimmt man nun an, dass der Nutzer auf Seiten, mit für ihn interessanten Inhalten, länger verweilt, als auf Seiten, für deren Inhalte er sich weniger interessiert, so ließe sich der Begriff „Zielseite“ und damit der Navigationsweg

auch wie folgt definieren: Ein Navigationsweg bildet sich aus einer Anfangsseite mit langer Verweildauer, gefolgt von einer oder mehreren Seitenanforderungen in kurzen Abständen und abgeschlossen durch die Zielseite mit wiederum einer langen Verweildauer, wobei diese Zielseite auch die Anfangsseite eines nachfolgenden Navigationsweges darstellen kann.

Abbildung 10: Navigationsweg als Kette von Seitenanforderungen

Die Bestimmung eines Navigationsweges gründet sich also neben den gesammelten Daten der Seitenanforderungen allein auf die berechnete Verweildauer der einzelnen Wegseiten. Dies bringt leider eine Reihe von Problemen mit sich:

Nicht aus jedem längeren Aufenthalt eines Nutzers auf einer Inhaltsseite kann sicher geschlossen werden, dass es sich dabei wirklich um die Seite mit den gewünschten Inhalten - also die Zielseite - handelt. Ebenso ist es möglich, dass der Nutzer auch nur für eine Weile abgelenkt ist (z.B. Telefonanruf) und seinen Navigationsweg später fortsetzen wird. Denkbar ist auch der Fall, dass der gewünschte Inhalt nur einen kurzen Aufenthalt auf dieser Seite erfordert (z.B. für einen Download), was die Erkennung des Zielpunktes eines Navigationsweges ebenfalls unsicher macht. Hier müssen also Maßnahmen getroffen werden, die helfen, derartige Situationen zu erkennen und eine Fehlinterpretation zu verhindern, z.B. unter Einbeziehung statistischer Verfahren.

Zu ermittelten Navigationswegen lassen sich - wie auch bei Aktionen und Seitenwechseln - gewisse Informationen ableiten. Neben der Häufigkeit und

Intensität der Nutzung ist hier auch die Geschwindigkeit der Navigation von Interesse.

Sonderfall: Wiederholtes Anfordern einer Seite

Browser bieten in der Regel eine “Aktualisieren“-Funktion. Diese dient dazu, die aktuelle Seite erneut zu laden, d.h. sie beim Server wiederholt anzufordern. Dabei wird diese Seitenanforderung zunächst wie jede andere Anforderung behandelt und ein neuer Protokolleintrag erzeugt. Die Möglichkeit solcher doppelter Einträge muss deshalb bei der Wegerkennung Berücksichtigung finden. Dies stellt allerdings kein großes Problem dar, da hierzu einfach aufeinanderfolgende Seitenaufrufe eines Nutzers verglichen und ggf. ignoriert werden müssen.

Sonderfall: “Vor“- bzw. “Zurück“’-Navigation / Browser-Cache Wesentlicher Bestandteil der Browserfunktionalität stellt die Navigation mit Hilfe der “Vor“- und “Zurück“-Schaltflächen dar. Ist eine angeforderte Seite vollständig geladen, so wird sie in der Regel vom Browser in einen dafür vorgesehenen Cache-Speicher abgelegt, um sie bei einem erneuten Aufruf schneller verfügbar machen zu können. Die Seite wird dann nicht neu vom Webserver angefordert, sondern direkt aus dem Browser-Cache geladen.

Abbildung 11: Anforderung einer Seite, Ablage im Cache und erneuter Aufruf. Der zweite Aufruf von Seite 1

geschieht ohne erneute Seitenanforderung

Der Vorteil eines schnelleren Seitenaufbaus für den Nutzer ist hier gleichzeitig ein Nachteil für das Personalisierungssystem, da es diesen Vorgang nicht direkt beobachten kann.

Abbildung 12: Verfälschte Navigationsdaten - Nutzer befindet sich scheinbar gleichzeitig auf Seite 2 und Seite 3

Jedoch erlaubt der verfälschte Datenbestand eine nachträgliche Rekonstruktion einer solchen Nutzernavigation, z.B. durch Einfügen zusätzlicher Seitenwechsel:

Abbildung 13: Rekonstruierter Weg nach Einfügen eines zusätzlichen Seitenwechsels

Sonderfall: Mehrere Browserfenster

Im Normalfall wird bei Betätigung eines Links die neue Seite in dem selben Browserfenster aufgebaut und ersetzt somit die aktuelle Seite. Allerdings kann der Nutzer den Browser auch veranlassen, die gewünschte Seite in einem gesonderten Browserfenster zu öffnen, wobei die aktuelle Seite im alten Browserfenster erhalten bliebe. Die Möglichkeit einer theoretisch beliebigen Anzahl von Browserfenstern eines Nutzers stellt ein schwieriges aber auch lösbares Problem für die Wegeerkennung dar.

Abbildung 14: Durch Klick auf Link „Seite 2“ wird ein neues Browserfenster geöffnet

Dieser Vorgang erscheint für das Personalisierungssystem zunächst als normaler Seitenwechsel. Dass „Seite 2“ in einem neuen Browserfenster angefordert wurde, kann es nicht feststellen. Navigiert der Nutzer nun abwechselnd in beiden Fenstern, so könnte sich beispielsweise folgendes Bild ergeben:

Abbildung 15: Wechselseitige Navigation mit zwei Browserfenstern

Da der erfasste Datenbestand zu Seitenanforderungen die Bezeichner sowohl der angeforderten Seiten und des verwendeten Links als auch der

Ursprungsseite umfasst, ist eine Behandlung solcher Situationen sehr gut möglich. Hierfür ist eine Reihe verschiedener Vorgehensweisen denkbar: Eine Variante stellt - ähnlich wie beim “Zurück“-Button-Problem - das Einfügen zusätzlicher imaginärer Seitenwechsel in den Datenbestand dar:

Abbildung 16: Bereinigung des Datenbestandes durch Einfügen eines imaginären Seitenwechsels und

Korrektur des zeitlichen Verlaufes (X steht für die unbekannte Aufenthaltdauer auf Seite 5)

Beide Wegstränge werden zu einem Navigationsweg vereint, indem der abgeschlossene Seitenstrang in den Hauptstrang eingefügt wird. Der zeitliche Verlauf muss dabei korrigiert werden, um eine spätere Ermittlung der Aufenthaltsdauer des Nutzers auf den einzelnen Seiten zu ermöglichen.

Als alternative Vorgehensweise ist eine unabhängige Betrachtung und Auswertung der beiden Wegstränge möglich. Für das obige Beispiel würde dies folgendes bedeuten:

Abbildung 17: Bereinigung des Datenbestandes durch unabhängige Betrachtung der Wegstränge und

Korrektur des zeitlichen Verlaufs

Der durch Öffnen des zweiten Browserfensters neu entstandene Wegstrang wird als eigenständig interpretiert. Der Haupt-Wegstrang bleibt dabei erhalten. Der zeitliche Verlauf der einzelnen Seitenanforderungen beider Stränge muss auch hier korrigiert werden.

3.2.2 Textbasierte Informationen

Wie wir bereits feststellten, können Nutzer durch das Anklicken eines aktiven Elementes einer Website interagieren. Ein solches Element kann z.B. ein Link sein. Handelt es sich um einen Formularbutton, so werden in der Regel auch Formulartexte übertragen, die vom Nutzer auf dieser Seite eingegeben wurden.

Aktive textbasierte Informationen

Neben Navigationsinformationen lassen sich deshalb auch textbasierte Informationen mit dem Nutzer in Zusammenhang bringen. Im oben genannten Fall liegen aktive, textbasierte Informationen vor, da diese aktiv vom Nutzer eingegeben wurden.

Passive textbasierte Informationen

Wir sprechen von passiven textbasierten Informationen, wenn Texte betrachtet werden, welche zwar nicht vom Nutzer eingegeben wurden, aber dennoch mit dem Nutzer in Zusammenhang gebracht werden können. Dies ist bei dynamischen Seiteninhalten der Fall. Nutzer treffen eine Aussage über die Qualität einer Seite, gemessen an ihrem aktuellen Interesse, indem sie kürzer oder länger auf dieser Seite verweilen. Um diese Aussage in ein Nutzerprofil einfließen zu lassen, bietet es sich an, die textuellen Informationen dieser Seite so zu verarbeiten, dass sie möglichst einfach abzuspeichern und zu interpretieren sind.

3.2.2.1 Verarbeitung von Textdaten

Bei der Datengewinnung wurden textuelle Eingaben des Nutzers sowie von der Anwendung bereitgestellte Texte, also beliebige textuelle Seiteninhalte, protokolliert. Auf der Datenebene handelt es sich hierbei zunächst nur um Zeichenketten. Erst wenn diese Terme in Relation zu bereits existierenden Informationen über die natürliche Sprache oder zu existierenden Informationen

über bisherige Nutzereingaben gebracht werden können, ist es möglich, daraus Informationen zu gewinnen und mit diesen das persönliche Profil des Nutzers zu beeinflussen. Dazu wollen wir an einem Beispiel betrachten, welche Informationen in Textdaten enthalten sein können und wie wir diese für unsere Personalisierungstechniken verwenden können. Nehmen wir einen beliebigen natürlichsprachlichen Term her: "New Orleans in der Nacht".

Es könnte sich bei dieser Phrase um eine Suchanfrage in einem Reiseportal handeln. Völlig unabhängig von der Suchfunktion würde es nun sinnvoll erscheinen, wenn ein Personalisierungssystem anhand dieses Suchausdrucks feststellen könnte, dass der Nutzer Interesse an Inhalten zum Thema "New Orleans" in Zusammenhang mit "Nacht" hat. Dabei sind wir soeben die ersten Schritte bereits gegangen. Zunächst haben wir intuitiv den Term in Wörter unterteilt, d.h. segmentiert. In diesem Fall ist das nicht schwierig, die Teilung wird anhand der Leerzeichen vorgenommen. Leerzeichen sind jedoch nicht der einzige Trenn-Operator. Auch Kommata, Satzzeichen und andere Sonderzeichen sind zu bedenken. Bei einigen Sonderzeichen muss wiederum beachtet werden, dass diese zwar Satz-und damit auch Wortgrenzen kennzeichnen, allerdings auch innerhalb eines Wortes als Bestandteil von Eigennamen auftreten: "amazon.com", "Yahoo!". Des Weiteren haben wir bereits intuitiv den Suchausdruck auf Kollokationen (siehe „Grundbegriffe zur Computerlinguistik“, Seite 5-121) untersucht und "New" sowie "Orleans" als zusammengehörige Wörter erkannt. Auch dies fiel uns nicht sonderlich schwer; etwas komplexer wird dieser Vorgang, wenn Kollokationen über den gesamten Term verstreut sind. Gerade Verbalphrasen treten oftmals nicht in direkter Nachbarschaft auf, so dass zwischen zusammengehörigen Wörtern durchaus andere Wörter stehen können. An dieser Stelle muss man sich jedoch fragen, in welchem Verhältnis der zu betreibende Aufwand zum erwarteten Erfolg steht. Noch mussten wir uns nicht festlegen, ob die Techniken der Computerlinguistik in Echtzeit

ausgeführt werden sollen oder nicht. Aber selbst wenn dies nicht der Fall ist, so können durchaus enorme Mengen an Textdaten zu verarbeiten sein. Ein hoher Rechenaufwand muss ausreichend gerechtfertigt sein. Schließlich wurden Wörter entfernt, die vermeintlich keine Bedeutung haben. Die Wörter "in" und "der" sind typische Funktionswörter (siehe Kapitel „Grundbegriffe zur Computerlinguistik“ Seite 5-121) mit sehr geringer Eigenbedeutung. So wurden schließlich aus dem Term "New Orleans in der Nacht" die so genannten bedeutungstragenden Einheiten "New Orleans" und "Nacht".

Fassen wir die bereits erfolgten Analysen noch einmal zusammen: (Originaltext) New Orleans in der Nacht Segmentieren New | Orleans | in | der | Nacht Bilden von Kollokationen New | Orleans | in | der | Nacht

Entfernen von Funktionswörtern

Abbildung 18: Schritte bei der Verarbeitung von Textdaten

Da diese Schritte erheblich komplexer sind, als es bisher den Anschein hatte, wollen wir hier nun einige konkrete Vorgehensweisen zu diesen Techniken näher erläutern.

Segmentieren eines Terms

Um einen Term zu segmentieren, gehen wir in mehreren Stufen vor. In der ersten Stufe wird bedingungslos an den Positionen getrennt, an denen bestimmte Trennzeichen auftreten. Die Liste dieser bedingungslosen Trennzeichen enthält alle Nicht-Wort-Zeichen, die nicht in der Liste der bedingten Trennzeichen enthalten sind, z.B. das Leerzeichen.

Reiseliteratur | bei | amazon. | de. | Wer | kauft | den | Lonely-Planet | online? Beispiel 20: Bedingungslose Segmentierung (Trennzeichen: Leerzeichen, Punkt)

Die Liste der bedingten Trennzeichen wird in der zweiten Stufe bemüht. Nun wird jedoch nicht mehr bedingungslos an den Positionen des Auftretens dieser Zeichen getrennt, sondern es wird zuvor die Umgebung der Zeichen untersucht. Getrennt wird nur, wenn in direkter linker oder rechter Nachbarschaft ein Nicht-Wortzeichen gefunden wird. Dieser Technik verhindert, dass ein Term wie "Notebook-Speicher" getrennt wird, da vor und nach dem bedingten Trennzeichen , hier einem Bindestrich, jeweils ein Wortzeichen steht. Dies ließe sich auch auf das Zeichen "." (Punkt) anwenden. Es würde dann der Term "amazon.de" nicht getrennt. Folgt auf den Punkt jedoch ein Leerzeichen, wie an einem Satzende, so würde der Punkt als Trennzeichen behandelt.

Dies ist nicht immer sinnvoll. Bei Formulareingaben kann man sich auf die syntaktische Genauigkeit der Nutzer nicht verlassen, so könnte auf einen Punkt auch ein Wortzeichen folgen, weil der Nutzer versehentlich kein Leerzeichen setzte. Auch in diesem Fall würde natürlich der Term als zusammengehörig betrachtet, es gilt also Fehlertoleranz gegen

Segmentierungsgenauigkeit abzuwägen und dabei auch die zu erwartenden Terme in Betracht zu ziehen.

Reiseliteratur | bei | amazon.de. | Wer | kauft | den | Lonely-Planet | online? Beispiel 21: Bedingte Segmentierung (Trennzeichen: Leerzeichen, bedingtes Trennzeichen: Punkt)

Kollokationen

Kollokationen werden in verschiedenen Gebieten der Computerlinguistik angewendet, und dementsprechend vielfältig sind die Techniken, die zur Ermittlung von Kollokationen eingesetzt werden. So stellen Anwendungen der

Lexikographie andere Anforderungen an die Qualität der Kollokationen, als Anwendungen des Information Retrieval.

Wir werden später noch genauer erläutern, wie die aus den gewonnenen Daten verarbeiteten Informationen in einem Personalisierungssystem zum Einsatz kommen können. Dies wird zeigen, dass die Ermittlung von Kollokationen sich weniger an sprachwissenschaftlichen als an

informationstheoretischen Aspekten orientieren soll. Wir interessieren uns z.B. weniger für sprachlich besonders interessante Kollokationen, die etwa in der computergestützten Lexikographie eine Rolle Spielen, als vielmehr für Kollokationen mit einer hohen inhaltlichen Aussagekraft bezüglich der Klassifikation eines Textes.

Als Argument für die Verwendung von Kollokationen zur Klassifikation natürlichsprachlicher Texte sei hier Firth's Theorie der Kontextuellen Bedeutung angebracht, in der die Rolle des Kontextes bezüglich der Bedeutung eines Wortes gezeigt wird.

Ermittlung von Kollokationen mittels einfacher Frequenzanalyse Die einfachste Möglichkeit, Kollokationen zu ermitteln, ist das Zählen gemeinsamen Vorkommens von Wörtern. Wird dabei auf Satzebene

vorgegangen, so werden nur Wörter betrachtet, die gemeinsam innerhalb eines Satzes auftreten. Inhaltliche Zusammenhänge sind jedoch nicht an Satzgrenzen gebunden. Für eine Ermittlung von Kollokationen, die weniger von sprachwissenschaftlichen als vielmehr von inhaltlichem Interesse sind, ist deshalb das Betrachten der Wörter innerhalb von Satzgrenzen weniger geeignet. Wortfenster eignen sich für eine solche Frequenzanalyse. Es wird dabei ein festgelegter Bereich von n Wörtern vor und nach einem aktuell betrachteten Wort analysiert.

Folgendes Beispiel demonstriert ein Wortfenster der Größe 5. Demnach werden insgesamt 5 Wörter betrachtet, 2 Wörter rechts und 2 links vom

aktuellen Wort. Nach 6 Durchgängen ist der Algorithmus am Wort „New“ angelangt und stellt das erstmalige Vorkommen der Wörter „sich“, „in“, „York“ und „gleich“ zu diesem Wort fest. Sollte in einem weiteren Satz erneut das Wort „York“ innerhalb eines Wortfensters gemeinsam mit dem Wort „New“ auftauchen, so wird der Zähler entsprechend erhöht.

“ 1 Bundeskanzler 2 Schröder 3 hat 4 sich 5 in 6 New 7 York 8 gleich 9 zweimal 10 mit 11 dem 12 blauen 13 Brief 14 der 15 EU-Kommission 16 befaßt.“ ²⁰ Beispiel 22: Textanalyse bei Betrachtung eines Wortfensters

Wendet man dieses Verfahren auf einen beliebigen Text an, so wird man feststellen, dass der überwiegende Teil der Kollokationen aus Funktionswörtern besteht. Kombinationen wie „mit dem“, „in der“ oder „durch das“, welche eine sehr geringe Eigenbedeutung haben, treten häufig auf. Dem kann durch einen so genannten „part-of-speech filter“ ²¹ entgegengewirkt werden, welcher nur solche Sprachmuster als Kollokationen zulässt, bei denen man anhand der Worttypen (Substantiv, Adjektiv etc.) vermuten kann, dass diese dafür in Frage kommen. Der Aufwand für dieses Verfahren ist jedoch relativ hoch und die benötigten Techniken sind weitgehend abhängig von einer konkreten Sprache.

Ermittlung von Kollokationen mittels Hypothesen-Test Bei der Ermittlung von Kollokationen sollen Wortkombinationen gefunden werden, die überdurchschnittlich häufig gemeinsam auftauchen. Was wir jedoch bisher nicht beachtet haben, ist die Häufigkeit des Auftretens der einzelnen Wörter einer potentiellen Kollokation.

Die Wahrscheinlichkeit des gemeinsamen Auftretens zweier gängiger Funktionswörter, z.B. „auf“ und „die“, ist wesentlich höher als die Wahrscheinlichkeit, dass weniger häufige Wörter gemeinsam auftreten. Werden die Wörter „Romeo“ und „Julia“ beispielsweise 20-mal gemeinsam in einem

²⁰ Frankfurter Allgemeine Zeitung, 13.Februar 2002.

²¹ Justeson and Katz (1995)

Text gefunden, wobei „Romeo“ insgesamt 25-mal und „Julia“ 30-mal auftritt, so ist dies ein wesentlich signifikanteres gemeinsames Auftreten als die Nachbarschaft von „auf“ und „die“, welche zwar öfter gemeinsam gefunden wurden, jedoch bereits einzeln auch wesentlich häufiger auftreten. Anhand eines Hypothesen-Tests kann diese Gegebenheit bei der Ermittlung von Kollokationen berücksichtigt werden: In einem Text mit Satzlänge N befinden sich a Sätze, in denen das Wort 1 auftaucht und b Sätze, in denen das Wort 2 auftaucht. Wir nehmen an, dass (1) das Wort nicht mehrmals in einem Satz auftauchen kann, (2) die Satzlänge keine Rolle spielt. Die Annahme (die wir später als H0 Hypothese aufstellen und ggf. verwerfen werden) lautet: Das Auftauchen der Wörter 1 und 2 in einem Satz ist unabhängig voneinander.

Wir wollen p(k | a, b, N) berechnen, also die Wahrscheinlichkeit, dass das Wort 1 und 2 k-mal gemeinsam in einem Satz auftauchen, gegeben dass das Wort 1 in a Sätzen und das Wort 2 in b Sätzen in einem Text mit N Sätzen auftauchen. Es gilt:

+ + − − − − − + − − k b a N a N a N k a a a b ( ) 1 1 1 1 !

⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ = N b a k p , , ( ) + − − − − + − − − b N k N k N k N N N k k b 1 1 1 1 ! !

Gleichung 3: Wahrscheinlichkeit für gemeinsames Auftreten zweier Wörter in einem Satz

Wie oben erwähnt, ist die Null-Hypothese, dass die Wahrscheinlichkeiten des Auftretens der beiden Wörter unabhängig voneinander sind. Wenn wir ein Signifikanz-Niveau von Sig = 0,9 benutzen gilt: q

Interpretation: Die Wahrscheinlichkeit dafür, dass bei N Sätzen, a Sätzen mit Wort 1 und b Sätzen mit Wort 2 beide Wörter höchstens k-mal gemeinsam in einem Satz auftauchen, liegt bei 90%. Wenn die tatsächliche Anzahl des Auftretens der Kollokation größer als q ist, dann bedeutet dies, dass die

Wahrscheinlichkeit des Ereignisses q unter der Null-Hypothese von 10% liegt. Bei einem Signifikanz-Niveau von 90% würden wir daher die Null-Hypothese verwerfen und damit die Kollokation für relevant halten.

Funktionswörter

Wir hatten bereits angesprochen, dass die geringe Eigenbedeutung bestimmter Wörter eventuell dafür spricht, diese so genannten Funktions- oder Stoppwörter bei der Informationsverarbeitung aus Gründen der Rechenzeit nicht weiter zu betrachten. Dies darf jedoch nicht im Konflikt mit dem Wortschatz der Anwendung stehen. Eigennamen oder Abkürzungen, die im Sprachgebrauch einer speziellen Anwendung üblich sind, sollten nicht fälschlicherweise als Funktionswörter betrachtet werden können. Würde z.B. in einem Musikportal eine Gruppe mit dem Namen "Echt" konsequent ignoriert, da dieses Wort als Funktionswort entfernt wird, so hätte dies eine Verfälschung der Personalisierung zur Folge.

Die Ermittlung dieser Wörter kann durch einen einfachen Vergleich mit einer Funktionswortliste vorgenommen werden. Da sich aufgrund der überschaubaren Anzahl dieser Wörter auch möglicherweise existierende Flexionsformen mit in diese Liste aufnehmen lassen, muss zuvor keine Grundformreduktion erfolgen. Die Wörter müssen also nicht auf ihre Grundform zurückgeführt werden.

Um Informationen abzuleiten, müssen wir uns jedoch auch im Klaren sein, wozu diese Informationen verwendet werden sollen. Dazu betrachten wir einige konkrete Anwendungen dieser textbasierten Personalisierung.

Vorschlag für Formular-Einträge

Beobachtet man Website-Benutzer, so kann man feststellen, dass in bestimmte Formulare immer wieder dieselben Werten eingegeben werden, z.B. die Adresse des Nutzers. Natürlich kann die Anwendung selbst diese Werte

bereits vorab in die Formulare einsetzen. Jedoch ist dies für den Betreiber einer Website relativ aufwendig und keineswegs flexibel. Sehr viel effektiver wäre es, wenn dem Betreiber ein Metasprachkonstrukt zur Verfügung gestellt würde, welches dem Personalisierungssystem signalisiert, das entsprechende Formularfeld vorab mit dem Wert zu füllen, dessen Eingabe durch den Benutzer am wahrscheinlichsten ist.

Wortschatz-Clusterbildung

Wünschenswert wäre es, einem Website-Betreiber eine einfache und flexible Möglichkeit zu geben, die Nutzung bestimmter Bereiche seines Angebotes nutzerspezifisch messen zu können. Die Nutzung kann in diesem Fall sowohl aktiv, z.B. durch Eingabe von Text in ein Formularfeld, als auch passiv, durch das Lesen eines Textes, geschehen. Eine konkrete Anwendung dieser Messung wäre z.B. die Erstellung eines anwendungsbezogenen dynamischen Wortschatzes unter Bezugnahme der Themengebiete dieser Anwendung. Dies soll an einem Beispiel illustriert werden.

Man stelle sich vor, der Nutzer eines Nachrichtenportals interessiert sich besonders für das Ressort Politik und verweilt bei Artikeln zum Thema Nah-Ost-Konflikt besonders lang. Bisher war es nun zwar möglich festzustellen, dass der Nutzer sich häufiger im Politik-Bereich des Portals aufhält, jedoch konnte dabei unter vertretbarem Aufwand nicht beachtet werden, dass es sich vor allem um Artikel zum Thema Nah-Ost-Konflikt handelte. Um dies zu ermöglichen, können sowohl ganze Seiteninhalte, als auch bestimmte durch den Betreiber spezifizierte Bereiche einer Seite bezüglich ihres Wortschatzes analysiert werden und gemeinsam mit den entsprechenden Verweildauern in ein Nutzerprofil einfließen. Bei der Analyse einer kompletten Seite werden zuvor vermeintlich relevante Textblöcke herausgestellt, um die Datenmenge zu verringern und eine Verzerrung des Wortschatzes durch z.B.

Menübezeichnung oder ähnliche nicht direkt auf den Seiten-Inhalt bezogene Texte zu vermeiden.

Eine spezielle Auszeichnung von Seitenbereichen durch den Betreiber ermöglicht eine explizite Benennung von Textblöcken, die dynamische Inhalte enthalten und damit eine sauberere Wortschatzgenerierung.

Beispiel 23: Explizite Spezifikation eines Textblocks im Seitenquelltext

Wurde ein solcher Wortschatz über einen ausreichenden Zeitraum generiert, so lässt sich nun für jeden beliebigen Text anhand dieses Wortschatzes eine Aussage über den Grad der Ähnlichkeit zum Nutzer-Wortschatz treffen, und somit eine Aussage über den Grad des vermuteten Nutzer-Interesses an diesem Text. Dies kann über eine interne Schnittstelle zwischen Personalisierungssystem und Anwendung bereits vor der Erzeugung einer HTML-Seite durch die Anwendung erfolgen. Somit kann sich bereits die Auswahl der darzustellenden Inhalte auf das vermutete Interesse des Nutzers beziehen. Soll diese interne Schnittstelle nicht verwendet werden, so kann mit Hilfe entsprechender Metasprachkonstrukte die Anordnung oder die Sichtbarkeit von Textblöcken vom Grad des Nutzerinteresses abhängig gemacht werden. Um auf unser Ausgangsbeispiel zurückzukommen: Auf der Einstiegsseite des Portals würden unter Verwendung von Metasprachkonstrukten die Nachrichtenblöcke der verschiedenen Ressorts nun so sortiert, dass politische Nachrichten weit vorn erscheinen, insbesondere Nachrichten zum Thema Nah-Ost-Konflikt, auch wenn diese möglicherweise dem Feuilleton-Ressort entstammen. Des Weiteren ließen sich Nachrichten ausblenden, an denen das

vermutete Interesse des Nutzers entsprechend niedrig wäre, womit die Wahrnehmungswahrscheinlichkeit der übrigen Inhalte stiege. Die Betrachtung von Informationen über die natürliche Sprache und die Informationen über bisherige Nutzereingaben gehen dabei Hand in Hand. Wie bereits bei den Grundbegriffen der Computerlinguistik herausgestellt wurde, sind statistische Methoden der Sprachverarbeitung im Fall eines modularen Personalisierungssystems erfolgversprechender als regelbasierte Methoden. Deshalb liegt der Schwerpunkt bei der textuellen Informationsverarbeitung klar bei den Informationen über bisherige Nutzereingaben bzw. bei der Verarbeitung aktueller nutzerspezifischer Terme in der Form, dass die Gewinnung von Wissen über den Nutzer durch statistische Operationen mit Hilfe der Informationen über bisherige Nutzereingaben möglich ist. Hier sei z.B. auf Techniken des kollaborativen Filterns verwiesen, welche bereits nähere Betrachtung fanden. Dennoch ist es sinnvoll, zuvor regelbasierte Techniken der Computerlinguistik anzuwenden. Für die Erstellung eines Interessenprofils sind vor allem Wörter mit hoher inhaltlicher Aussagekraft relevant. Da die Berechnung eines solchen Semantik-Wertes jedoch gerade bei einem dynamischen Wortschatz im Zusammenhang mit einer Personalisierung höchstwahrscheinlich nicht praktikabel ist, soll ein umgekehrter Weg gegangen werden. Anstatt inhaltlich aussagekräftige Wörter herauszustellen, werden Wörter mit einer geringen eigenständigen Bedeutung entfernt. Es handelt sich dabei um so genannte Stoppwörter, auch Funktionswörter genannt. Listen dieser Wörter existieren für beliebige Sprachen, eine solche Funktion stellt also keine Beschränkung des Einsatzbereiches eines Personalisierungssystems dar. In Kombination mit einer performanten Erkennung der Sprache eines Terms können diese Funktionswörter vollautomatisch aus einem Term isoliert werden, selbst in multilingualen Anwendungen. Auch hier wird die flexible Einsetzbarkeit, die ein modulares Personalisierungssystem bieten muss, nicht eingeschränkt. Als

performante Spracherkennung ²² bietet sich zu diesem Zweck eine auf Trigrammen und Funktionswörten basierende Erkennung an (siehe Kapitel „Grundbegriffe zur Computerlinguistik“, Seite 1-5). Es wird dabei mit Hilfe von einfachen statistischen Methoden auf der Basis von sprachspezifischen Trigramm- sowie Funktionswortlisten ein Wahrscheinlichkeitswert für die Zugehörigkeit des Textes zu einer oder mehreren Sprachen, welche dem System bekannt sind.

Nachdem Funktionswörter aus dem Term entfernt wurden, bietet sich eventuell eine Grundformreduktion der einzelnen Wörter an. Dies ist sinnvoll, da Grundformen normalerweise eine hohe inhaltliche Übereinstimmung mit ihren Flexionsformen haben und bei einem Vergleich zwischen Nutzerwortschatz und einem beliebigen Text dann eine wesentlich höhere Übereinstimmung vieler Wörter auftritt. Allerdings kann der Aufwand dieser Reduktion abhängig von der entsprechenden Sprache relativ hoch sein.

Da oftmals insbesondere Eigennamen oder Substantive, die meist in der Grundform oder in wenigen verschiedenen Flexionsformen auftreten, eine hohe Aussagekraft bezüglich des Inhaltes eines Textes haben, gilt es abzuwägen, ob der Aufwand und die Sprachbarrieren, die eine Grundformreduktion mit sich bringt, lohnenswert sind.

Durch die Bearbeitung eines Textes in der oben beschriebenen Art und Weise erzeugen wir aus Textdaten Informationen, die in Relation zur natürlichen Sprache stehen. Diese Informationen können nun in Abhängigkeit von der Datenquelle weiterverarbeitet werden.

3.2.2.2 Verarbeitung von textbasierten Informationen Für die Bereitstellung bestimmter Funktionalitäten muss das

Personalisierungssystem auf den Nutzerwortschatz zugreifen können. Mit Hilfe

²² Mit Spracherkennung ist hier natürlich nicht die automatische Erkennung von gesprochener

natürlicher Sprache gemeint, sondern die Ermittlung der (National-) Sprache eines Textes.

des Nutzerwortschatzes werden Techniken wie die individuelle

Rechtschreibkontrolle realisiert. Diese Techniken werden später näher erläutert. Das folgende Datenbankkonzept ermöglicht eine modulare Speicherung von Wortschatzinformationen.

Das zentrale Element dieses Konzeptes ist die abstrakte Einheit „Meaning“. Diese entspricht der Bedeutung eines oder mehrerer Wörter, auch sprachübergreifend. Synonyme z.B. erhalten identische MeaningIDs. Das Konzept einer Wortschatzdatenbank auf Basis von Bedeutungseinheiten kann im Bereich des Information Retrieval erhebliche Vorteile gegenüber einem Konzept auf Wortebene bringen. Wir möchten dies an einem Beispiel zeigen: Nehmen wir an, es soll die Ähnlichkeit zwischen dem Wortschatz eines Nutzers und einem Text ermittelt werden, um eine Aussage über das vermutete Interesse des Nutzers an diesem Text zu treffen. Auf Wortebene würden die Begriffe „KFZ“ und „Kraftfahrzeug“ keine Übereinstimmung ergeben und somit auch nicht den Wert des vermuteten Interesses des Nutzers an diesem Text erhöhen. Auf Bedeutungsebene hingegen wird beiden Begriffen dieselbe Identifikation zugewiesen, da es sich um Synonyme handelt. In der Tabelle Word werden die eigentlichen Wörter gespeichert, d.h. das, was man unter dem Ausdruck „Wort“ versteht. Es lassen sich die Sprache sowie der Worttyp (Substantiv, Verb etc.) zuordnen. In der Tabelle WordText

werden schließlich die eigentlichen Worttexte gespeichert. Dies hat zwei Gründe:

Zum einen gibt es gerade bei multilingualen Wortschatzdatenbanken sehr viele Wörter, deren Worttext identisch ist, die sich jedoch im Worttyp, in der Sprache oder in der Bedeutung unterscheiden. Es wäre also nicht sehr ökonomisch, die identischen Worttexte zu jedem Wort zu speichern. Zum anderen wiederspräche es der Idee eines bedeutungsorientierten Wortschatzkonzeptes, da ein Wort eben nicht durch den Worttext definiert wird, sondern sich aus einer Kombination von Bedeutung, Sprache und Worttext fundiert.

Ein Problem, welches mit diesem Konzept verbunden ist, haben wir jedoch noch nicht erwähnt. Die automatische Herleitung der Bedeutung eines Wortes ist nicht trivial. Um ein vom Nutzer verwendetes Wort diesem Schema gemäß einzuordnen, muss entweder eine Relation zu einer bereits existierenden Bedeutung gefunden werden oder eine neue Bedeutung erstellt werden. Letzteres ist automatisch kaum möglich, zumindest nicht, wenn Bedeutungen etwa in der im obigen Beispiel gezeigten Form verwendet werden sollen. Die Zuordnung zu einer vorhandenen Bedeutung ist jedoch praktikabel. Ist dies nicht möglich, so wird ein neues abstraktes Wort angelegt, für welches keine

Bedeutungsrelation erstellt wird. Es sei an dieser Stelle auf weiterführende Literatur zum Thema „Word Sense Disambiguation“ ²³ verwiesen. Für eine initiale Füllung der Datenbank nach diesem Schema wird empfohlen, auf bereits existierende Datenquellen mit einer ähnlichen Struktur zuzugreifen, etwa WordNet ²⁴ oder EuroWordNet ²⁵ .

²³ Li, Xiaobin et al.

²⁴ http://www.cogsci.princeton.edu/~wn/ (abgerufen am 10. Januar 2002)

²⁵ http://www.hum.uva.nl/~ewn/ (abgerufen am 10. Januar 2002)

3.3 Wissensgewinnung

Wie im Kapitel „Informationsgewinnung“ (Seite 3-54) beschrieben, können aus den einfachen Protokolldaten von Seitenanforderungen zunächst unmittelbar verschiedene Informationen, wie Aktionen, Seitenwechsel, Navigationswege und textbasierte Informationen gewonnen werden. Diese Informationen können nun wiederum auf vielfältige Weise interpretiert werden und erlauben komplexe Schlüsse, sowohl zu Eigenschaften des Nutzers als auch zu Eigenschaften der Anwendung selbst.

Die an dieser Stelle beschriebenen Verfahren sind als Ideenskizzen zu verstehen - nicht als fertige Konzepte. Dies muss Gegenstand weiterer Forschungsarbeit sein.

3.3.1 Wissen über den Nutzer

Das Ziel, Wissen über den Nutzer zu gewinnen, hat natürlich einen besonders hohen Stellenwert. Grundidee der Personalisierung ist schließlich, dem Nutzer und seinen individuellen Eigenschaften besser gerecht werden zu können.

Die direkt aus den gesammelten Daten gewonnenen Informationen erlauben bereits recht umfangreiche Personalisierungstechniken. Allerdings eignen sie sich auch sehr gut als Grundlage für verschiedene Verfahren zur Gewinnung von abstraktem Wissen über die reale Person, die sich hinter dem Nutzer verbirgt. Natürlich hat dieses Wissen dabei nur in Verbindung mit der konkreten Anwendung Gültigkeit.

Hierbei handelt es sich neben erfragbaren Informationen (z.B. Interessengebiete) auch um Informationen, die sich nicht direkt vom Nutzer erfragen lassen (z.B. Kenntnisstand/Erfahrungslevel, Gewohnheiten).

3.3.1.1 Erfahrungslevel

Das Erfahrungslevel eines Nutzers bezeichnet den Umfang seiner Kenntnisse im Umgang mit Computer und Internet im Allgemeinen und speziell im Bezug zur personalisierten Anwendung. Für die Ermittlung des Erfahrungslevels ist es erforderlich, möglichst viele dafür relevante Informationen über den Nutzer zusammenzuführen. Dies können sowohl durch Beobachtung gewonnene als auch vom Nutzer erfragte Informationen sein. Die Ermittlung kann als Schätzung verstanden werden, basierend auf den Daten des Nutzers in Bezug zu den Daten aller anderen Nutzer der Anwendung. Hierfür wird eine Reihe von Beurteilungskriterien herangezogen und jedes Einzelkriterium in Relation zu Minimal- und Maximalwert dieses Kriteriums aller anderen Nutzer bewertet. Dies hat den Vorteil, dass keinerlei absolute Regeln für die Beurteilung des Erfahrungsumfangs definiert werden müssen. Vielmehr kann sich das Verfahren am durchschnittlichen Erfahrungslevel aller Nutzer orientieren.

Beispiel 25: Aufstellung möglicher Kriterien und deren Gewichtung für die Beurteilung des Erfahrungslevels

eines Nutzers

3.3.1.2 Interessengebiete

Nachdem im Kapitel „Verarbeitung von textbasierten Informationen“ (Seite 3-77) Grundsätzliches zur Strukturierung und Speicherung erläutert wurde, wird nun das Wissen über Interessengebiete des Nutzers, welches sich aus diesen Informationen ableiten lässt, betrachtet. Untersuchen wir zunächst den Fall, dass die Wortschatzinformationen aus aktiven Textdaten stammen. Nachdem diese Daten verarbeitet wurden, liegen Wörter und Kollokationen vor, die mit dem Nutzer in Zusammenhang gebracht werden sollen. Diese können direkt in die Tabelle UserWord in der Wortschatzdatenbank aufgenommen werden. Über die InputID werden die Einträge ihrer Herkunft zugeordnet, so können später formular- und nutzerabhängige Eintragsvorschläge realisiert werden. Da passive Informationen keiner aktiven Quelle, d.h. keinem Formular, zugeordnet werden können, ist in der Tabelle UserWord der Eintrag einer PageID vorgesehen. Vom Anwender gelesene Texte sollen in Zusammenhang mit seinem Wortschatz gebracht werden, welcher indirekt Aussagen über das Interessenprofil zuläßt. Ebenso wie bei der Verarbeitung aktiver textbasierter Informationen werden alle relevanten Wörter dem Wortschatz zugeordnet, gemeinsam mit einem Verweis auf die Quellseite. Diese Vorgehensweise kann beträchtliche Ressourcen in Anspruch nehmen. Deshalb sollte das Hinzufügen passiver Textinformationen optional und nicht obligatorisch geschehen. Um eine Seite oder einen Text zu verarbeiten und auf diese Weise mit dem Nutzer in Zusammenhang zu bringen (sofern der Text gelesen wurde), muss der zu verarbeitende Bereich metasprachlich ausgezeichnet werden.

Beispiel 26: Bestimmung eines Textblocks zur Verarbeitung

Um die Verwendung und Auswertung der Wortschatzdatenbank performanter zu gestalten, enthält die Tabelle UserWord eine Spalte Weight, in der die Gewichtung des jeweiligen Eintrags festgehalten wird. Einträge aus passiver Quelle werden in der Regel schwächer gewichtet als aktive Einträge des Nutzers. Die Berechnung eines Beziehungswertes zwischen dem Nutzerwortschatz und einem Text kann als vermutetes Interesse des Nutzers an diesem Text interpretiert werden und mit folgendem SQL-Statement ermittelt werden: SELECT sum(Weight)

FROM UserWord UW INNER JOIN Word W ON UW.WordID=W.WordID

INNER JOIN WordText WT ON WT.WordTextID=W.WordTextID

WHERE UW.UserID=[UserID] AND (WordText = ‘Wort1’ OR

WordText = ‘Wort2’ OR WordText = ‘Wort3’) Beispiel 27: Berechnung eines Wortschatz - Text Beziehungswertes

Dieser Beziehungswert ist jedoch nicht normiert, kann daher nur im direkten Vergleich Verwendung finden, z.B. zur Realisierung einer Ranking-Funktionalität, die wir später noch besprechen werden. Zur Normierung des Beziehungswertes müssen Umfang des Nutzerwortschatzes und Länge des zu vergleichenden Textes berücksichtigt werden. Um den bereits erwähnten Vorteil eines bedeutungsorientierten Wortschatzkonzeptes zu nutzen, wird der Beziehungswert in zwei Schritten berechnet. Im ersten Schritt werden die MeaningIDs für alle relevanten Wörter des Textes ermittelt. SELECT W.MeaningID

FROM Word W INNER JOIN WordText WT ON

WT.WordTextID=W.WordTextID

WHERE WordText = ‘Wort1’ OR WordText = ‘Wort2’ OR WordText

= ‘Wort3’

Beispiel 28: Ermittlung der Synonymgruppen für die Berechnung eines Beziehungswertes auf

Bedeutungsebene

Dies ist notwendig, damit im zweiten Schritt die Übereinstimmung des Textes zum Nutzerwortschatz anhand der MeaningIDs, also gewissermaßen anhand der Synonymgruppen, berechnet werden kann. SELECT sum(Weight)

FROM Word W INNER JOIN UserWord UW ON W.WordID=UW.WordID

WHERE W.MeaningID=[MeaningID1] OR W.MeaningID=[MeaningID2]

OR W.MeaningID=[MeaningID3]

Beispiel 29: Berechnung eines Beziehungswertes auf Bedeutungsebene

Inwiefern der berechnete Beziehungswert von Nutzen sein wird und welche konkreten Funktionalitäten sich auf Basis eines solchen Wertes realisieren lassen, werden wir im Kapitel „Anwendung“ (Seite 3-94) besprechen.

3.3.2 Wissen über die Anwendung

Den höchsten Stellenwert für den Betreiber hat der Wunsch, die Inhalte und Strukturen des Angebots bestmöglich auf die Interessen und Bedürfnisse der Nutzer abzustimmen. So kann auf Dauer eine ausreichend große Zahl von Nutzern durch ein attraktives Angebot gewonnen und gehalten werden. Neben dem eigentlichen Anliegen - der Personalisierung der Inhalte und Oberflächen - verfolgt unser Ansatz daher auch das Ziel, dem Betreiber der Website die Möglichkeit zu einer umfassenden Analyse der Site-Strukturen zu geben. Bisher stellt die Auswertung der Server-Logfiles i.A. die einzige Möglichkeit zur Gewinnung von Informationen über die Anwendung dar - und dies auch nur in eingeschränktem Umfang. Mit Hilfe von Logfiles ist es beispielsweise nur schwer bzw. gar nicht möglich, Zielgruppeninformationen zu gewinnen.

thewall.nbg.net - - [01/Mar/2002:07:53:11 +0100] "GET / HTTP/1.0" 200 26378

"http://www.brandenburg.de/kommunen/mol.htm" "Mozilla/2.02 [de] (OS/2; I)"

thewall.nbg.net - - [01/Mar/2002:07:53:13 +0100] "GET /assets/images/kachel.gif

HTTP/1.0" 200 2166 "http://www.15370-petershagen.de/" "Mozilla/2.02 [de] (OS/2; I)"

thewall.nbg.net - - [01/Mar/2002:07:53:13 +0100] "GET /assets/images/dot_clear.gif

HTTP/1.0" 200 54 "http://www.15370-petershagen.de/" "Mozilla/2.02 [de] (OS/2; I)"

thewall.nbg.net - - [01/Mar/2002:07:53:13 +0100] "GET /assets/images/dot_clear.gif

HTTP/1.0" 200 54 "http://www.15370-petershagen.de/" "Mozilla/2.02 [de] (OS/2; I)"

thewall.nbg.net - - [01/Mar/2002:07:53:13 +0100] "GET /assets/images/dot_clear.gif

HTTP/1.0" 200 54 "http://www.15370-petershagen.de/" "Mozilla/2.02 [de] (OS/2; I)"

thewall.nbg.net - - [01/Mar/2002:07:53:17 +0100] "GET / HTTP/1.0" 304 -

"http://www.brandenburg.de/kommunen/mol.htm" "Mozilla/2.02 [de] (OS/2; I)"

thewall.nbg.net - - [01/Mar/2002:07:53:19 +0100] "GET /assets/images/kachel.gif

HTTP/1.0" 304 - "http://www.15370-petershagen.de/" "Mozilla/2.02 [de] (OS/2; I)"

thewall.nbg.net - - [01/Mar/2002:07:53:19 +0100] "GET /assets/images/dot_clear.gif

HTTP/1.0" 304 - "http://www.15370-petershagen.de/" "Mozilla/2.02 [de] (OS/2; I)"

thewall.nbg.net - - [01/Mar/2002:07:53:19 +0100] "GET /assets/images/dot_clear.gif

HTTP/1.0" 304 - "http://www.15370-petershagen.de/" "Mozilla/2.02 [de] (OS/2; I)"

thewall.nbg.net - - [01/Mar/2002:07:53:19 +0100] "GET /assets/images/dot_clear.gif

HTTP/1.0" 304 - "http://www.15370-petershagen.de/" "Mozilla/2.02 [de] (OS/2; I)"

thewall.nbg.net - - [01/Mar/2002:07:53:20 +0100] "GET /assets/images/dot_clear.gif

HTTP/1.0" 304 - "http://www.15370-petershagen.de/" "Mozilla/2.02 [de] (OS/2; I)"

thewall.nbg.net - - [01/Mar/2002:07:53:20 +0100] "GET /assets/images/dot_clear.gif

HTTP/1.0" 304 - "http://www.15370-petershagen.de/" "Mozilla/2.02 [de] (OS/2; I)"

thewall.nbg.net - - [01/Mar/2002:07:53:20 +0100] "GET /assets/images/dot_clear.gif

HTTP/1.0" 304 - "http://www.15370-petershagen.de/" "Mozilla/2.02 [de] (OS/2; I)"

thewall.nbg.net - - [01/Mar/2002:07:53:20 +0100] "GET /assets/images/dot_clear.gif

HTTP/1.0" 304 - "http://www.15370-petershagen.de/" "Mozilla/2.02 [de] (OS/2; I)"

thewall.nbg.net - - [01/Mar/2002:07:53:20 +0100] "GET /assets/images/dot_clear.gif

HTTP/1.0" 304 - "http://www.15370-petershagen.de/" "Mozilla/2.02 [de] (OS/2; I)"

Abbildung 20: Auszug aus einem Server-Logfile

3.3.2.1 Nutzungsschwerpunkte (räumlich/zeitlich)

Die erfassten Nutzerdaten setzen sich hauptsächlich aus den protokollierten Anforderungen von Inhaltsseiten zusammen. Neben der Bezeichnung der angeforderten Seite wird auch der genaue Zeitpunkt der Anforderung gespeichert. Diese Daten können in vielerlei Hinsicht als Indikator für Nutzungsschwerpunkte des Angebotes interpretiert werden. Als Nutzungsschwerpunkte sind hier zum einen Seiten bzw. Gruppen zusammenhängender Seiten mit signifikant höheren Anforderungszahlen und zum anderen Zeitintervalle mit erhöhten Anforderungszahlen zu verstehen. Diese Informationen lassen sich leicht aus dem erfassten Datenbestand gewinnen.

Diese Auswertung kann nun nicht nur allgemein für den gesamten Datenbestand durchgeführt werden, sondern auch zeitabhängig, d.h. es lässt sich die Frage beantworten, welche Teile des Angebots zu welcher Tageszeit, zu welchem Wochentag oder gar zu welcher Jahreszeit besonders intensiv genutzt werden. Diese Informationen sind für den Betreiber sehr wertvoll. So kann er z.B. besondere Events, wie Livechats und Votings, gezielter platzierensowohl räumlich als auch zeitlich. Natürlich lassen sich so auch Werbeflächen wesentlich präziser schalten und effizienter abrechnen.

Ein weiterer Vorteil solcher Auslastungsinformationen ist die Möglichkeit, Mängel in der Struktur des Angebotes aufzudecken. Wird beispielsweise ein Teil des Angebots überhaupt nicht oder nur in sehr geringem Maß genutzt, so könnte ein Fehler in der Sitestruktur die Ursache sein, z.B. ein so genannter „toter Link“, vor allem dann, wenn der Inhalt der betroffenen Teile des Angebots eine stärkere Nutzerzahl erwarten ließ.

3.3.2.2 Zielgruppeninformationen

Im Abschnitt „Wissen über den Nutzer“ (Seite 1-5) wurden einige Verfahren zur Gewinnung von abstraktem Wissen über die Nutzer skizziert. Dieses Wissen lässt sich natürlich auch hervorragend statistisch aufbereiten. Auch hierzu bieten sich vielfältige Möglichkeiten, von denen einige im Folgenden kurz vorgestellt werden sollen.

3.4 Integration

In den vorangegangenen Kapiteln wurden Verfahren zur Gewinnung von Daten, Informationen und Wissen zu Eigenschaften von Nutzern und Anwendung erläutert. Nun geht es darum, diesen Informationsschatz für Personalisierungsfunktionen zum Einsatz zu bringen. In diesem Kapitel sollen dazu einige Ansätze und Ideen geliefert werden. Die Integration des Personalisierungssystems kann, neben im Aufbau befindlichen Angeboten, auch in bestehende statische oder dynamische Angebote erfolgen. In Abhängigkeit von diesen Kriterien ergeben sich drei mögliche Stufen bzw. Integrationsvarianten:

• Einzelbetrieb der Daten-, Informations- und Wissensgewinnung zur Auswertung (ohne Personalisierungsfunktionen)

• Einfache Personalisierungsfunktionen unter Verwendung der Metasprache

• Komplexe Personalisierungsfunktionen unter Verwendung einer internen Schnittstelle (API)

3.4.1 Metasprache

Im Rahmen dieser Arbeit wollen wir keine komplette Metasprache zur Implementierung von Personalisierungstechniken entwickeln. Werden Anforderungen an ein Personalisierungssystem untersucht, so ist jedoch auch dieser wesentliche Bestandteil zumindest so genau zu betrachten, dass eventuelle konzeptionelle Probleme deutlich würden. In den folgenden Abschnitten sollen die Anforderungen an dieses Hilfsmittel erläutert, das zugrundeliegende Konzept aufgezeigt und die Realisierung diskutiert werden.

Um eine Kommunikation zwischen Betreiber und Personalisierungssystem zu ermöglichen, wird eine Schnittstelle benötigt. Diese Schnittstelle soll der

Steuerung bzw. Regelung von Personalisierungstechniken dienen. Um einen Anforderungskatalog zu erstellen, müssen zunächst jedoch die Bedürfnisse der Zielgruppe, d.h. der Betreiber, klar sein. Außerdem sollte geklärt werden, was diese Schnittstelle leisten soll und was nicht. Für die Integration von Personalisierungstechniken sind vermutlich entweder Gestalter oder Web-Programmierer oder aber beide zuständig. Damit der Aufwand für die Einarbeitung in ein Werkzeug zur Implementierung von Personalisierungstechniken möglichst gering ist, sollten Methoden verwendet werden, die dieser Zielgruppe vertraut sind. Es bietet sich der Einsatz einer Metasprache an, da sowohl Gestalter als auch Web-Programmierer in der Regel mit Dokumentbeschreibungssprachen, Skriptsprachen oder

Programmiersprachen vertraut sind, bzw. Werkzeuge nutzen, die solche Sprachen implementieren.

Diese Metasprache sollte sich am Syntax, den gängigen Formulierungsweisen und den Dogmen der Dokumentbeschreibungssprache HTML, der Skriptsprache JavaScript und der serverseitig ausgeführten Skriptsprachen PHP bzw. ASP orientieren. Auch Denkweisen bei der Verwendung verbreiteter Content-Management-Systeme sollten den

Denkweisen bei der Implementierung von Personalisierungstechniken auf Basis dieser Metasprache nicht widersprechen. Werden diese Anforderungen beim Sprachdesign beachtet, so wird es den potentiellen Anwendern dieser Sprache den Einstieg wesentlich leichter machen. Neben menschlichen Aspekten sind auch technische Gegebenheiten relevant. Bei der Entwicklung von Websites kommen oft visuelle HTML-Editoren zum Einsatz, die einen direkten Eingriff in den Quelltext nicht ermöglichen bzw. zumindest erschweren. Das gleiche gilt für CM-Systeme, bei denen das Einfügen beliebiger Anweisungen in den HTML-Quelltext nicht immer machbar ist. Ein Ausweg ist die Gestaltung sämtlicher metasprachlicher Konstrukte in Form von HTML-Kommentaren, da alle relevanten Editoren und CM-Systeme das Einfügen von Kommentaren erlauben. Ein weiterer Vorteil dieser Methode

ist die Robustheit, d.h. bei einem Ausfall des Personalisierungssystems haben die Elemente der Metasprache keinerlei Einfluss auf die Darstellung der Seiten. Selbstverständlich soll es möglich sein, die Funktionalität des Personalisierungssystems zu erweitern, ohne dabei in Konflikt mit der Metasprache zu geraten. Die Skalierbarkeit ist demnach ebenso wichtig wie die Flexibilität. Somit sollten beim Entwurf bereits Eventualitäten bedacht und im Sprachdesign berücksichtigt werden.

Leider kann die Dokumentbeschreibungssprache HTML nicht gerade als objektorientiert bezeichnet werden. Jedoch halten objektorientierte Denkweisen auch in die Welt der Internet-Entwicklung verstärkt Einzug (z.B. XML, Java). Gerade bei komplexen bzw. abstrakten Daten ist der Einsatz objektorientierter Techniken sinnvoll, da die Entwicklung und Pflege überschaubarer ist, der Einsatz modularer ist und die Denkweisen eher der natürlichen Sicht entsprechen als bei prozeduralen Techniken. Deshalb sollte sich das Sprachdesign an objektorientierten Konzepten ausrichten. Bei der Einführung eines Produktes oder einer Technik ist es wichtig, verschiedene Stufen des Nutzungsumfangs zu ermöglichen. Will ein Betreiber, z.B. aus Zeitgründen, die Personalisierung zunächst nur in geringem Umfang nutzen, so muss ihm das auch mit geringem Aufwand möglich sein. Dazu bedarf es einer Metasprache, die mit geringem Sprachumfang bereits Grundfunktionen realisieren kann und erst bei komplexeren Anforderungen einen umfassenderen Wortschatz benötigt. Diese Eigenschaft erleichtert den Einstieg enorm und ist z.B. eines der Erfolgsgeheimnisse der Programmiersprache PERL.

Auch Performance-Gesichtspunkte spielen eine Rolle. Durch Integration der Metasprachbestandteile werden die entsprechenden Quelltexte natürlich umfangreicher. Auch wenn die Metasprachbestandteile des Quelltextes nicht zum Client übermittelt werden, da der Parser des Personalisierungssystems diese extrahiert und auf deren Basis eine Manipulation des eigentlichen

Seitenquelltextes vornimmt, so stellen längere Quelltexte zumindest auf Serverseite eine höhere Last dar, da diese Quelltexte von den verarbeitenden Skripten oder zumindest vom Webserver geladen werden müssen. Demzufolge sollte beim Sprachdesign schließlich auch dies beachtet werden.

3.4.2 API

Die Integration von Personalisierungsfunktionen mit Hilfe

metasprachlicher Konstrukte erlaubt nur einfache Anpassungen, da kein neuer Content erzeugt werden kann. Nur die bereits im HTML-Quelltext enthaltenen Inhalte können modifiziert (z.B. versteckt , geordnet) werden. Für die meisten einfache Anwendungen wird der Leistungsumfang der Metasprache ausreichend sein. Dennoch ist die Schaffung eines direkten Zugangs zu den Personalisierungsfunktionen im Rahmen einer speziellen API für komplexere Anwendungen sinnvoll.

Dies könnte z.B. als Perl- oder PHP-Modul realisiert werden. So wären sämtliche Funktionen des Personalisierungssystems innerhalb der

seitengenerierenden Skripte verfügbar. Dieser direkte Zugriff ermöglicht die Erzeugung von Inhaltsseiten in Abhängigkeit von Personalisierungsfunktionen, d.h. auf Basis der Eigenschaften und Präferenzen des Nutzers bzw. der Eigenschaften der Anwendung.

Der Umfang der durch die API bereitgestellten Funktionen könnte sich in folgende drei Ebenen gliedern:

Einfache Abfragesprache für Daten

Ein Lesezugriff auf alle gesammelten Daten ermöglicht dem Betreiber die Entwicklung eigener Auswertungs- und Analysefunktionen. Denkbar wäre z.B. die Verwendung von - evtl. vereinfachter - SQL-Syntax für die Abfragesprache. Die Nutzung dieser Funktionalität erfordert natürlich grundlegende Datenbank-Kenntnisse.

Abfragefunktionen für Daten und Informationen Sehr viele Abfragefunktionen können vordefiniert werden. Dazu könnten beispielsweise Funktionen wie getClickStream() (Liste der Aktionen eines Nutzers) oder getHistory() (Liste der zuletzt angeforderten Seiten) gehören. Der Funktionsumfang sollte dabei alle Funktionen für den Zugriff auf gesammelte Daten und den daraus direkt gewonnenen Informationen umfassen.

Abfragefunktionen für Wissen

Durch Verwendung der API kann auch auf das aus gesammelten Daten und Informationen gewonnene Wissen mit Hilfe von Funktionen, wie z.B. getKnowledgeLevel() (Erfahrungslevel eines Nutzers) zugegriffen werden.

3.5 Anwendung

3.5.1 Personalisierung

Wie bereits in der Einleitung erwähnt wurde, sind gewisse Vorbehalte gegenüber personalisierten Anwendungen zu spüren, gerade unter professionellen Nutzern. Schließlich muss sich eine Personalisierung an der Qualität ihrer Funktionen messen lassen. Um zu zeigen, welche Funktionalitäten mit dem in dieser Arbeit vorgestellten modularen, nicht integrativen Ansatz möglich sind, sollen im Folgenden einige konkrete Anwendungsfälle dargestellt werden. Anhand dieser Beschreibungen soll das Verständnis der bisher erläuterten Konzepte vertieft werden. Es wird dabei jeweils ein prototypischer Einsatz der entsprechenden Funktionalität anhand des Reiseportals blickreich.de illustriert und dessen Implementierung und Auswirkung diskutiert. Die Auswahl der Anwendungsfälle wurde so getroffen, dass alle besprochenen Konzepte noch einmal anhand praktischer Beispiele nachvollzogen werden können.

3.5.1.1 Sichtbarkeit

Betrachtet man als gewöhnlicher Anwender z.B. ein durchschnittliches Nachrichtenportal, so stellt man vor allem auf der Startseite eine große Anzahl von verschiedenen Informationsblöcken fest. Der Grund dafür ist, dass die Betreiber bestrebt sind, innerhalb ihrer Zielgruppe möglichst alle Interessengebiete bereits auf der Startseite abzudecken, um Besucher zum Verweilen zu animieren. Dies hat natürlich auch negative Auswirkungen. Da ein nicht personalisiertes Portal die individuellen Interessen seiner Besucher nicht berücksichtigen kann, werden diese mit einer Vielzahl von Informationen konfrontiert, die für sie nicht relevant sind. Dies hat zur Folge, dass die Wahrnehmungswahrscheinlichkeit für eventuell relevantere Informationen auf der aktuellen Seite geringer wird, da sich die Aufmerksamkeit des Besuchers auf eine höhere Anzahl von Informationen verteilt.

Es sollte verhindert werden, dass Besuchern Informationen präsentiert werden, welche für sie höchstwahrscheinlich nicht von Interesse sind. Im Folgenden Beispiel ist ein Informationsblock rot markiert, welcher nur für bestimmte Besucher relevant ist.

Beispiel 33: Beeinflussung der Sichtbarkeit von Elementen in Abhängigkeit der Besucherinteressen

Es handelt sich um einen TV-Tipp, der auf der Startseite erscheint, wenn davon ausgegangen werden kann, dass der aktuelle Besucher des Reiseportals Interesse an der Region Australien hat. Dieses Interesse kann der Besucher auf verschiedene Art und Weise demonstrieren. Etwa durch das Einstellen von Bildern, Reiseberichten oder Forum-Beiträgen mit Bezug zu dieser Region. Oder durch längeres Verweilen auf Seiten mit Beiträgen zum Thema Australien. Um die Sichtbarkeit dieses Informationsblocks von bestimmten Kriterien abhängig zu machen, benutzen wir auch hier wieder ein Metasprachkonstrukt.

Beispiel 34: Quelltextbeispiel für die Beeinflussung der Sichtbarkeit von Elementen in Abhängigkeit der

Besucherinteressen

Es wird im Quelltext ein Container definiert, der alle Elemente umschließt, deren Sichtbarkeit beeinflusst werden soll. Ist dies nicht möglich, so können auch mehrere Container mit denselben Attributen gebildet werden. Das Attribut visibility="relation(this,’Australien’)>=0.5" weist den Parser des Personalisierungssystems an, den Container nur dann im Quelltext zu belassen, wenn der aktuelle Nutzer (this) zur Klasse Australien eine Beziehung mit dem Mindestgrad 0.5 hat. In diesem Fall wird dieser Klassenbeziehungswert durch das oben erwähnte Besucherinteresse beeinflusst, beispielsweise dadurch, das der Besucher Fotos zum Thema Australien hochlädt. Ob 0.5 ein sinnvoller Wert ist bzw. welcher Wert tatsächlich eingesetzt werden sollte, muss anhand von praktischen Tests ermittelt werden. Ziel sollte es sein, Besuchern, die eventuell Interesse an einer Information haben, diese nicht vorzuenthalten und auf der anderen Seite den daran nicht interessierten Besucher diese Information nicht aufzudrängen. Diese Funktionalität ist übrigens nicht auf Interessenklassen beschränkt. Es bietet sich beispielsweise außerdem an, bestimmten aktiven Elementen eine Erfahrungsklasse zuzuweisen. Werden diese Elemente von Besuchern benutzt, so wird der entsprechende Klassenbeziehungswert beeinflusst, so wie es auch bei Interessenklassen der Fall ist. So können z.B. Navigationselemente, die nur von erfahrenen Besuchern genutzt werden, mit der Klasse Profi versehen werden. Die Sichtbarkeit sämtlicher Elemente des Portals, welche nur für

erfahrene Nutzer verfügbar sein sollen, wird dann von einem hohen Klassenbeziehungswert zur Klasse Profi abhängig gemacht.

3.5.1.2 Ranking

Insbesondere bei Navigationselementen ist es oft der Fall, dass diese nicht völlig ausgeblendet werden sollen, wenn ein Besucher vermutlich nicht darauf zugreifen wird, sondern dass die Anordnung der Elemente vom Interesse oder der Nutzung eines Besuchers abhängig sein sollte. Im Folgenden Beispiel werden dem Besucher Links zu Bildkategorien präsentiert, in Form eines Web-Kataloges wie man ihn von Yahoo! kennt.

Beispiel 35: Personalisierte Anordnung von Elementen (hier: Links zu Unterkategorien)

Unter den fett geschriebenen Hauptkategorien sind jeweils drei Unterkategorien aufgelistet, soweit vorhanden. Zu den meisten

Hauptkategorien gibt es in diesem Fall weitere Unterkategorien, jedoch ist deren Auflistung aus Gründen des Designs nicht erwünscht. Um dem Nutzer dennoch das direkte Auswählen seiner favorisierten Unterkategorie zu ermöglichen, sollten jeweils diese aufgelistet werden, die vom Nutzer bisher am häufigsten ausgewählt wurden.

Um die Häufigkeit der Nutzung eines aktiven Elementes abzufragen, greifen wir auf das Kriterium usage der Metasprache zu: usage(this)gibt den Grad der Nutzung des jeweiligen Elementes im Verhältnis zu den anderen Elementen dieser Elementklasse zurück und bezieht sich dabei auf den aktuellen Nutzer (this). Wird keine Elementklasse angegeben, so gilt die aktuelle Seite als Elementklasse. In unserem Beispiel werden alle Unterkategorien als Elementklasse zusammengefasst. Ein Klassennutzungswert von 1 würde bedeuten, dass das entsprechende Element bisher das einzige Element der Klasse ist, welches benutzt wurde. Ein Klassennutzungswert von 0,5 entspricht der Nutzung des Elementes in 50% der Fälle. Wir benötigen in diesem Beispiel keinen absoluten Klassennutzungswert, sondern verwenden diesen als Kriterium für die Sortierung unserer Unterkategorie-Links:

Europa

Asien

Amerika

Afrika

Australien

Mittlerer

Osten

Beispiel 36: Quelltextbeispiel für das Anzeigen der drei meistgenutzten Unterkategorien, bezogen auf einen

Nutzer

Mit items="Bild-Unterkategorie *" werden die zu sortierenden Elemente innerhalb dieses Blocks definiert (d.h. die Elementklasse), da sich auch weitere Elemente innerhalb des Blocks befinden können, die nicht sortiert werden sollen. Durch die Bedingung limit=”0,3” werden nach der Sortierung nur die ersten drei der in items spezifizierten Elemente innerhalb dieses Blockes dargestellt. Nachdem der Quelltext vom Parser des Personalisierungssystems verarbeitet wurde, sind schließlich statt des gesamten Metasprachkonstruktes die drei gewünschten Links vorzufinden.

Europa

Asien

Mittlerer

Osten

Beispiel 37: Quelltext nach dem Parsen

Das Ranking kann natürlich nicht nur auf Links angewendet werden, sondern beispielsweise auch auf Informationsblöcke. Anstatt des orderby- Kriteriums usage würdean dieser Stelle das Kriterium relation Verwendung finden, welches wir bereits beim vorigen Beispiel angewandt haben, um das Interesse eines Nutzers zu einer Elementklasse abzufragen.

3.5.1.3 Textuelles Ranking

Nicht immer ist es dem Betreiber einer Website möglich, Textblöcke von Hand einer bestimmten Inhaltsklasse zuzuordnen. In diesem Fall kann das Ranking, welches im letzten Abschnitt erläutert wurde, nicht angewandt werden, da die Beziehung eines Nutzers zur Klasse eines Textes natürlich nicht bestimmt werden kann, wenn die Klasse des Textes nicht bekannt ist. Dennoch ist eine Ranking-Funktionalität auch bei Textblöcken realisierbar, für die nicht explizit eine Inhaltsklasse spezifiziert wurde. Gesucht ist auch hier eine Aussage über die Beziehung eines bestimmten Nutzers zu einem Objekt. Ist diese Beziehung stark, so würde das Objekt bei einem Ranking entsprechend weit oben erscheinen. Jedoch wird in diesem Fall das Objekt nicht durch eine bestimmte Klasse repräsentiert, sondern durch die Informationen, die in dem Textblock selbst stecken. Diese werden dargestellt als Textvektor. Um eine Aussage über die Beziehung zwischen diesem Textvektor und dem Nutzer zu treffen, wird als Vergleichswert der Nutzerwortschatz, ebenfalls repräsentiert durch einen Textvektor,

herangezogen. Wird dieser Vergleich für mehrere Textblöcke ausgeführt, so kann einer Sortierung dieser Blöcke anhand der Vergleichswerte stattfinden.

Diese Technik ermöglicht das Ranking textueller Inhalte, ohne dass eine Klassifikation durch den Betreiber notwendig ist. Die Qualität hängt jedoch sehr stark vom generierten Nutzerwortschatz und von den Inhalten der zu sortierenden Textblöcke ab. Damit ein aussagekräftiger Vergleich zwischen Nutzerwortschatz und Textblock möglich ist, sollten Überschneidungen des Wortschatzes auftreten.

Abbildung 21: Schnittmenge zwischen Nutzerwortschatz und Text als Messwert für das vermutete Interesse

eines Nutzers an einem nicht klassifizierten Text

Anhand des Schaubildes kann man bereits erkennen, dass bei sehr kurzen Texten oder einem kleinen Nutzerwortschatz eine Überschneidung, wenn überhaupt vorhanden, so gering sein kann, dass eine signifikante Aussage kaum zu treffen ist. Deshalb kann es hilfreich sein, neben den Wörtern des Nutzerwortschatzes und des Textes selbst, auch Synonyme dieser Wörter in eine Prüfung der Übereinstimmung mit einzubeziehen.

Abbildung 22: Berücksichtigung der Synonyme des Nutzerwortschatzes und des Textes

Da die inhaltliche Übereinstimmung zwischen Nutzerwortschatz und Text gemessen werden soll und Synonyme eine starke inhaltliche Beziehung zueinander haben, wurde dieser Ansatz zur indirekten Erweiterung der

Wortmengen gewählt. Eine konkrete Formel zum Vergleich der Wortvektoren, bei der auch eine stärkere Gewichtung der direkten Wortmengen berücksichtigt werden kann, soll hier nicht ausgearbeitet werden. Generell verspricht eine statische Klassifikation, beispielsweise die explizite Zuweisung der Inhaltsklasse Politik zu einem Textblock aus dem Politik-Ressort eines Nachrichten-Portales, bessere Ergebnisse bezüglich des Rankings als eine dynamische Klassifikation anhand der Wörter. Da eine solche Klassifikation durch den Betreiber manchmal jedoch nicht mit vertretbarem Aufwand möglich ist, z.B. bei durch die Nutzer bereitgestellten Inhalten, wurde diese Technik eingeführt.

Der folgende Quelltext implementiert die besprochene Funktionalität. Dabei wird analog zum Standard-Ranking vorgegangen. Die zu sortierenden Elemente werden mittels items="Text *" spezifiziert. Als Sortier-Kriterium

wird orderby="relation(this,this)" verwendet, wobei (this,this) sich auf den aktuellen Nutzer und das jeweilige aktuelle Element während der Iteration über den Blockinhalt bezieht. Um dem Personalisierungssystem schließlich mitzuteilen, dass die Sortierung anhand eines dynamischen Wortschatzvergleiches vorgenommen werden soll, wird der Typ des Block-Befehls angegeben: type=”TextRanking”.

Beispiel 39: Quelltextbeispiel für das Ranking von Textblöcken

3.5.1.4 Hotlinks

Eine nahe liegende und ebenso nützliche Funktionalität eines Personalisierungssystems ist das Bereitstellen von Hotlinks. Es handelt sich dabei um Links, welche die durch einen Nutzer am meisten angesteuerten Ziele repräsentieren, ausgehend von der aktuellen Seite. Unter „Ziel“ wird jedoch nicht nur ein direktes, mit einem Klick erreichbares, Verweisziel verstanden, sondern der Endpunkt eines Navigationsweges, der auf der aktuellen Seite begann. Somit lässt sich die Navigation wesentlich effektiver gestalten.

Beispiel 40: Hotlinks - Verknüpfungen zu den von dieser Seite aus am meisten angesteuerten Zielen dieses

Nutzers

Für eine Implementierung von Hotlinks müssen zunächst die Links, welche als potentielle Hotlinks indiziert werden sollen, innerhalb des Quelltextes spezifiziert werden. Bei Verwendung eines Links als Hotlink kann ein abweichender Linktext gewünscht sein, da der Link dann auf einer anderen Seite erscheint. In unserem Beispiel ist der Linktext „Nordamerika“ auf der Bildkategorie-Seite sicherlich ausreichend, auf der Startseite würde ein Link mit diesem Verweistext jedoch sein Ziel völlig unzureichend beschreiben. Deshalb ist es bei der Spezifikation eines Hotlinks möglich, einen alternativen Verweistext anzugeben. Dieser wird dann anstatt des normalen Linktextes dort eingesetzt, wo dieser Link als Hotlink verwendet wird.

Regionen/Nordamerika”-->

Nordamerika

Beispiel 41: Spezifikation eines Verweises als Hotlink

Mit Hilfe von Metasprachkonstrukten kann auf Hotlinks zugegriffen werden:

->

#Link.Text# |

Beispiel 42: Einbindung der drei meistgenutzten Hotlinks

Der Abfragetyp wird mit query=“Hotlink“ angegeben. Um innerhalb des Abfragekörpers auf die Elemente des jeweiligen Hotlinks zugreifen zu können (z.B. auf die URL oder den Linktext), wird ein Objektname definiert: object=”Link”.

3.5.1.5 Prefilling

Mitunter kommt es vor, dass in bestimmten Formularen Nutzer häufig dieselben Einträge eingeben. Wenn vom Personalisierungssystem eine gewisse Regelmäßigkeit bei der Eingabe eines Formulartextes festzustellen ist, kann dieses Formular bereits bei der Bereitstellung der entsprechenden Seite diesen Text enthalten und dem Nutzer die Eingabe damit ersparen.

Im obigen Beispiel können Besucher im Reiseportal eigene Bilder hochladen. Dabei kann unter anderem der verwendete Kameratyp eingegeben werden. Stellt das Personalisierungssystem fest, dass der aktuelle Nutzer in dieses spezielle Formularfeld immer wieder eine bestimmte Kamera eingegeben hat, so kann dieser Text bereits vorher in das Formular eingetragen werden.

Beispiel 44: Implementierung eines Formular-Prefillings

Die Angabe weist das Personalisierungssystem an, den in diesem Formular meistverwendeten Eintrag des Nutzers auszugeben. Um eine signifikante Aussage treffen zu können, wird

eine Schwellwertprüfung vorgenommen, d.h. erst bei einer ausreichenden Anzahl von Nutzereingaben wird ein Vorschlag ausgegeben. Durch die Angabe query=PrefillLast kann statt der häufigsten auch die letzte Eingabe des Nutzers als Formularvorschlag ausgegeben werden.

3.5.1.6 Individuelle Rechtschreibkontrolle

Die Realisierung einer nutzerspezifischen Rechtschreibkontrolle mag etwas aufwendig und übertrieben erscheinen. Faktisch bedeutet dies jedoch keinen Mehraufwand, wenn ohnehin ein nutzerspezifischer Wortschatz generiert wird. Am Beispiel des Reiseportals wird zugleich auch ein erheblicher Vorteil klar: Durch die Überprüfung der Eingaben anhand eines dynamischen Wortschatzes, nämlich dem sich ständig weiterentwickelnden Nutzerwortschatz, werden auch Wörter abgedeckt, die in einem statischen Wortschatzlexikon nicht vorhanden sind, z.B. zahlreiche spezielle Eigennamen wie z.B. Städtenamen.

Auch hier wird für eine signifikante Aussage natürlich ein gewisser Mindestwortschatz benötigt. Die Eingabe wird zunächst in Wörter segmentiert. Ist ein eingegebenes Wort noch nicht im Nutzerwortschatz vorhanden, so wird geprüft, ob ein ähnliches Wort existiert, d.h. ob es sich also möglicherweise um einen Tipp- oder Schreibfehler handelt. Bei einer Ähnlichkeitsprüfung sollten folgende Gegebenheiten beachtet werden: Tippfehler: Unter Beachtung des Tastaturlayouts stellen die Nachbartasten eine geringere Abweichung dar als örtlich entferntere Tasten.

Phonetische Gegebenheiten: Abhängig von der jeweiligen Sprache können ähnlich klingende Laute zu Schreibfehlern führen.

Fehlende / Überflüssige Buchstaben: Es kommt gelegentlich vor, dass Buchstaben beim Eingeben vergessen oder zusätzlich eingegeben werden.

Buchstabendreher: Durch das versehentliche Vertauschen von Buchstaben können Tippfehler entstehen.

Für die Implementierung der Rechtschreibkontrolle steht die interne Schnittstelle zum Personalisierungssystem zur Verfügung. Eine Realisierung mittels Metasprachkonstrukten ist nicht praktikabel, da die Ablaufsteuerung der Website vom Ergebnis der Rechtschreibkontrolle beeinflusst wird. Bei der

Auswertung der Formulareingaben wird im Fall eines Schreib- oder Tippfehlers meist zu einer anderen Seite verzweigt, es sei denn, in den Eingaben wurden keine Fehler erkannt. Eine solche Ablaufsteuerung kann besser realisiert werden, wenn die Prüfung der Nutzereingaben bereits bei der Generierung der Seite vorliegt. Dies ist nur durch einen Zugriff auf die interne Schnittstelle mögliche. Wie dieser konkrete Zugriff implementiert wird, soll hier jedoch nicht betrachtet werden.

3.5.1.7 Inhaltsvorschlag

Bei umfangreichen Websites werden Inhalte meist aus einer Datenbank gelesen und dann dynamisch in die jeweilige Seite eingebunden. Um bei der Auswahl dieser Inhalte bereits auf individuelle Interessen einzugehen, kann die Anwendung auf das Personalisierungssystem zugreifen. Auch dies lässt sich über die interne Schnittstelle realisieren. Die Berechnung des persönlichen Interessenwertes eines Nutzers an bestimmten Inhalten basiert dabei auf denselben Prinzipien wie beim Ranking bzw. dem textuellen Ranking von Inhalten. Es wird also entweder die Beziehung eines Nutzers zu einer statischen Klasse abgefragt, z.B. der Inhaltsklasse ‚Reisetipps Nordamerika’, oder die Inhalte werden auf Basis des dynamischen Wortschatzvergleiches bewertet. Anhand der Ergebniswerte, die die Anwendung vom Personalisierungssystem erhält, kann entschieden werden, ob die gerade bewerteten Inhalte in die Seite eingebunden werden sollen oder nicht.

Prinzipiell ließe sich eine solche Funktionalität auch mit Hilfe des Metasprachkonstruktes visibility realisieren, indem die Inhalte innerhalb der Seite mit einer entsprechenden visibility-Bedingung verknüpft werden. Bei umfangreichen Inhalts-Datenbanken kann so jedoch bereits bei der Auswahl der Inhalte gezielt auf die Bedürfnisse des Besuchers eingegangen werden.

Im oben dargestellten Beispiel wird auf eine Termindatenbank des Reiseportals zugegriffen. Die Einträge in dieser Datenbank sind den in diesem Portal existierenden Inhaltsklassen zugeordnet. So kann die Anwendung bereits vor der Einbindung der Inhalte in die auszugebende Seite prüfen, wie hoch das Interesse des aktuellen Nutzers an diesem Eintrag ist, da die Beziehung des Nutzers zu diesen Inhaltsklassen bekannt ist.

3.5.1.8 Zusatzinformationen bei intensiver Nutzung

Bei der Gestaltung eines Interfaces hat man oft das Problem, dass fortgeschrittene Anwender andere Anforderungen stellen als Einsteiger. Wer beispielsweise nicht sehr häufig in Foren aktiv ist, dem sind Begriffe wie „Thread“ nicht unbedingt geläufig und komplexe Informationen über zurückliegende Foren-Beiträge können schnell Verwirrung stiften. Deshalb wird in dem folgenden Beispiel gezeigt, wie es möglich ist, solche erweiterten Informationen nur fortgeschrittenen Nutzern zugänglich zu machen.

Im rot markierten Bereich sind die Zusatzinformationen zu sehen. Diese werden nur dann eingeblendet, wenn das Personalisierungssystem eine häufige Nutzung des Forums durch den aktuellen Nutzer feststellt. Den Anwendern, die bereits mit den bisherigen Funktionen des Forums vertraut sind, werden diese erweiterten Informationen zur Verfügung gestellt. Es kann davon ausgegangen werden, dass die Aufmerksamkeit, die ein Anwender aufbringen muss, um die bisher dargestellten Informationen zu verarbeiten, geringer ist, wenn die Anordnung, Farbgebung, Gestaltung, d.h. die gesamte Erscheinung dieser Informationen, bereits vertraut ist. Deshalb werden weitere Informationen erst dann angezeigt, wenn diese Vertrautheit erreicht wurde.

Um dies zu implementieren, gibt es auch in diesem Anwendungsfall mehrere Möglichkeiten. Eine Abfrage der Nutzungsintensivität über die interne Schnittstelle zum Personalisierungssystem ist dann sinnvoll, wenn die Bereitstellung der Informationen relativ aufwendig ist, da dann bereits vorher ermittelt werden kann, ob diese Informationen überhaupt dargestellt werden

sollen oder nicht. Liegen die Informationen für fortgeschrittene Anwender ohnehin vor, dann kann die Realisierung dieser Funktionalität auch mittels der Metasprache vorgenommen werden.

[erweiterte Informationen]

Beispiel 52: Anzeige von Zusatzinformationen für fortgeschrittene Nutzer

Wir verwendeten das Kriterium usage(this,’Forum’) um die Sichtbarkeit der Informationen zu steuern. Damit das Personalisierungssystem diese Anweisung auswerten kann, muss außerdem das Objekt Forum spezifiziert werden:

Kleinanzeigen (1)

Reisepartner (0)

Reisetipps und Erfahrungen(2)

...

Beispiel 53: Spezifikation eines Containers für die Elemente, deren Nutzungsintensivität gemessen werden soll

Es wird die Nutzungsintensivität aller Elemente gemessen, die durch das Objekt Forum spezifiziert werden. Damit können in unserem Beispiel alle Elemente in eine Messung eingeschlossen werden, die mit der Nutzung des Forums in Zusammenhang stehen, auch seitenübergreifend.

3.5.1.9 Auswahl ähnlicher Inhalte mittels kollaborativen Filterns Die viel beachtete Technik des kollaborativen Filterns erlaubt es, anhand von Ähnlichkeiten zwischen den Präferenzen verschiedener Nutzer eine Aussage über die vermutete Präferenz bestimmter Inhalte für einen Nutzer zu treffen, auch wenn dieser diese Inhalte noch nicht bewertet hat. Auch in unserem

Beispielportal kann dies sehr effektiv eingesetzt werden. Grundlage sind die von Nutzern betrachteten Bilder.

Nehmen wir an, ein aktueller Nutzer a betrachtete eine Menge X von Bildern. Ein weiterer Nutzer b betrachtete eine Bildmenge Y.

Abbildung 23: Ermittlung potentiell interessanter Bilder mittels kollaborativen Filterns

Viele Elemente dieser Mengen überschneiden sich, es kann daher davon ausgegangen werden, dass beide Nutzer ähnliche Maßstäbe bei der Selektion von Bildern anlegen. Deshalb wird vermutet, dass auch die nicht in Menge X enthaltenen Bilder, die durch Nutzer b betrachtet wurden, für Nutzer a interessant sein könnten. Gesucht wird die Differenzmenge Y \ X bei ausreichend großer Schnittmenge X ∩ Y.

Um das oben gezeigte Beispiel zu implementieren, benötigt das Personalisierungssystem folgende Informationen:

Damit die Mengen X sowie Y n automatisch gebildet werden können, müssen Elemente (Bilder), welche diesen Mengen zugeordnet werden sollen, im Quelltext spezifiziert werden.

Beispiel 55: Spezifikation eines Elementes

Das Attribut name=“BildMenge“ spezifiziert den Namen der Menge, dem das Element zugeordnet werden soll. Ein eindeutiger Elementbezeichner wird durch Angabe von item=“[ElementID]“ vergeben, wobei [ElementID] von der Anwendung bereitgestellt werden muß. Beim Parsen des Quelltextes durch das Personalisierungssystem wird dieser Quelltextbereich ausgewertet und das angegebene Element der Menge zugeordnet oder entsprechend gewichtet, falls es schon vorhanden ist. Dies geschieht natürlich für alle Nutzer, es werden also die Mengen X und Y ⁿ gebildet.

Sollen schließlich Inhaltsvorschläge in eine Seite eingebunden werden, so können die vorgeschlagenen Elemente über die interne Schnittstelle abgefragt werden, wobei das aktuelle Element x, sowie der aktuelle Nutzer a angegeben werden müssen. Zurückgegeben wird eine Menge, die Elemente enthält - in diesem Fall Bildidentifikationsnummern, welche als Inhaltsvorschläge verwendet werden können. Diese Menge kann auf Basis der im Kapitel „Kollaboratives Filtern (collaborative filtering):“ (Seite 2-25) erläuterten Methoden berechnet werden.

3.5.2 Analysen und Statistiken

Alle gewonnenen Informationen und Statistiken zu Eigenschaften von Anwendung und Nutzern müssen dem Betreiber komfortabel zugänglich gemacht werden. Dies könnte z.B. als Web-Applikation realisiert werden.

Website-Strukturen

Die Strukturen einer Website sind i.A. sehr komplex und können als Graph visualisiert werden. In einem solchen Graph repräsentieren die Knoten einzelne Inhaltsseiten. Die Kanten stehen für die Links, die die Seiten miteinander verbinden.

Eine Vielzahl der gesammelten Daten bzw. gewonnenen Informationen kann direkt an diesen Graph angetragen werden. So z.B. die Nutzungshäufigkeit oder -intensität der Links.

Jedoch stellt die Generierung des Strukturgraphs einer Website auf Basis der protokollierten Seitenanforderungen und Aktionselemente kein triviales Problem dar. Ziel ist es, die Generierung des Strukturgraphs weitgehend automatisiert geschehen zu lassen, d.h. der Betreiber soll den Graphen nicht explizit definieren müssen. Den wichtigsten Schritt hierzu stellt die Identifikation der Seiten als Orte dar. Diese Orte bilden die Knoten des Graphen. Im Gegensatz zur Identifikation von Inhaltsseiten (siehe „3.1.2.2 Identifikation der angeforderten Seite“, Seite 3-37) sollen die Seiten hier nicht im Sinn von „Inhaltseinheiten“, sondern vielmehr als Lokalitäten identifiziert werden. Dies soll an folgendem Beispiel verdeutlicht werden: Die ‚News’-Seite einer beliebigen Website enthält eine Reihe von Nachrichtenbeiträgen in der Form Überschrift und Kurztext. Durch Klick auf eine Überschrift gelangt man auf eine neue Seite mit dem Volltext der entsprechenden Nachricht. Diese Volltextseite wird nach Auswertung eines bei der Anforderung als Parameter übermittelten Identifikators dynamisch generiert.

Wie im Kapitel „Datengewinnung“ (Seite 3-31) beschrieben, wird nun neben der Übersichtsseite jede einzelne Seite mit einem Nachrichten-Volltext als eigenständige Inhaltsseite identifiziert. Für die Generierung des Strukturgraphen sind diese verschiedenen Inhaltseiten gleichen Typs allerdings irrelevant. Daher müssen alle typverwandten Inhaltsseiten als ein und derselbe Ort interpretiert werden. Im konkreten Beispiel ist dies der Ort „Nachrichten-Volltext“.

Solche und ähnliche Zusammenhänge stellen bei den meisten Anwendungen den Regelfall dar. Nur ein sehr kleiner Anteil der identifizierten Inhaltsseiten repräsentiert auch einen eigenen Ort. Die meisten der Inhaltsseiten können einer durch Typverwandtschaft gebildeten Gruppe zugeordnet werden und repräsentieren gemeinsam ein und denselben Ort. Es geht im Folgenden also darum, den Begriff der Typverwandtschaft von Inhaltsseiten zu definieren.

Die Identifikation der Inhaltsseiten geschah im wesentlichen durch Auswertung aller übermittelten Parameter (URL, Post/Get, Quelltext). Zu jeder dieser Inhaltseiten wurde dann auch eine Liste der Parameter in der Datenbank abgelegt. Bezogen auf das Problem der Typverwandtschaft gibt es nun zwei Arten von Parametern: ortsbestimmende Parameter und Parameter ohne Einfluss auf den Ort. Für die Identifikation der Orte sind natürlich nur die ortsbestimmenden Parameter relevant. Zur Verdeutlichung noch einmal zurück zu obigem Beispiel:

Folgende Seitenanforderungen wurden als einzelne Inhaltsseiten identifiziert und protokolliert:

Beispiel 56: Identifizierte Inhaltsseiten mit teilweise ortsbestimmenden Parametern

Die Tabelle zeigt das Problem deutlich. Sie enthält zehn identifizierte Inhaltsseiten mit insgesamt aber nur zwei verschiedenen Orts-Typen: der Nachrichtenübersicht (kein Parameter newsid) und dem Nachrichtenvolltext (newsid=x). Für dieses Beispiel ist newsid demnach der einzige ortsbestimmende Parameter. Zusätzlich könnte man auch anonym (kein Parameter userid) und nicht-anonym (userid=x) aufgerufene Inhaltsseiten unterscheiden. Dann wären vier statt zwei Orte unterscheidbar. Die Unterscheidung der ortsbestimmenden Parameter von irrelevanten Parametern kann nicht automatisch geschehen. Diese Aufgabe muss der Betreiber übernehmen. Vorteilhaft wirkt sich hier die Tatsache aus, dass diese Definition erst zur Analyse angewandt wird und so jederzeit geändert werden kann.

Der Betreiber muss also für jeden auftretenden Parameter spezifizieren, wie dieser bei der Ortsidentifikation behandelt werden soll. Die folgenden drei Varianten sind beispielsweise denkbar:

• Parameter wird ignoriert

• Parameter wird nur auf Existenz bzw. Nicht-Existenz geprüft

• Parameter und Wert wird berücksichtigt

Nutzerstatistiken

Ebenso wie die Website-Struktur können auch die Informationen und Statistiken zu Nutzern und Nutzergruppen grafisch aufbereitet dem Betreiber zur Verfügung gestellt werden. Dieser kann sich auf diese Weise ein genaueres Bild von den Hauptnutzergruppen des Angebotes machen.

4. Zusammenfassung und Ausblick

Unser modularer Ansatz ermöglicht den Einsatz von

Personalisierungstechniken in beliebigen Online-Informationssystemen, da konsequent eine modulare Lösung angestrebt wurde. Dieses Konzept weist wesentliche Vorteile auf:

• Neben einfachen Websites können auch umfassende

• Durch offene Schnittstellen werden Transparenz und Flexibilität ermöglicht.

• Der nichtintegrative Ansatz gestattet eine klare Trennung von

• Auch höchst komplexe Personalisierungstechniken lassen sich implementieren.

Abschließend kann festgestellt werden, dass auch bei einer strikten Teilung von Personalisierungssystem und Anwendung auf Basis der erläuterten Konzepte eine Personalisierung im WWW möglich ist.

5. Anhänge

5.1 Grundbegriffe zur Computerlinguistik

Für die Verarbeitung von textbasierten Informationen bedarf es Techniken der Computerlinguistik. Dazu sollen hier einige Grundbegriffe erläutert werden.

Stoppwörter / Funktionswörter

Betrachtet man einen natürlichsprachlichen Text, so fallen zahlreiche Wörter auf, die für sich genommen keinerlei oder kaum semantische Informationen beinhalten. Solche Wörter nennt man Funktionswörter. Artikel und Pronomen gehören zu dieser Klasse. Bei der Anwendung einiger Techniken der Computerlinguistik ist es üblich, diese Wörter zuvor aus dem Text zu entfernen. Dies hat nur minimale qualitative Auswirkungen, kann jedoch erhebliche Performance-Vorteile bringen.

Kollokationen

Als Kollokationen werden Phrasen oder gemeinsam auftretende Wörter bezeichnet, wenn durch dieses gemeinsame Auftreten ein neuer Sinn entsteht,

der sich nicht aus den Wörtern selbst ableiten lässt. Um Kollokationen in einem Text zu erkennen, bedarf es spezieller Techniken, da es sich auf den ersten Blick um normale, durch Leerzeichen getrennte Wörter handelt. Dennoch lohnt der Aufwand der Erkennung oftmals, da diese eine besondere Aussagekraft haben.

n-Gramme

Bestimmte Zeichenketten sind charakteristisch für bestimmte Sprachen. So ist das Trigramm "ing" besonders häufig in der englischen Sprache zu finden, "sch" hingegen typisch für deutsche Texte. n-Gramme können zur Ermittlung der Sprache benutzt werden, in der ein Text oder Textabschnitt verfasst wurde.

Text-Vektor-Modelle

Ein Text kann als Vektor dargestellt werden, wobei es sich bei den Skalaren um die Elemente des Textes handelt. Diese Elemente können beliebige Bestandteile des Textes sein, z.B. n-Gramme, Wörter oder Kollokationen. Diese Darstellungsform hat den Vorteil, dass sich aus der Linearen Algebra bekannte Operationen anwenden lassen.

²⁶ Antoine de Saint-Exupéry “Der Kleine Prinz“

Regelbasierte vs. statistische Methoden

Es gibt zwei verschiedene Ansätze zur Verarbeitung natürlicher Sprache. Versteht man eine Sprache als unveränderliches Regelwerk, so kann man versuchen, diese Regeln so zu formulieren, dass sie maschinell lesbar sind, z.B. mit Hilfe einer Prädikatenlogik. Leider bedarf es eines hohen initialen manuellen Aufwandes, um ein solches System zu erstellen. Auch die Übertragbarkeit auf andere Sprachen ist nicht ohne weiteres möglich, da sich diese meist eines anderen Regelwerks bedienen. Hinzu kommt die geringe Flexibilität dieser Technik, da Regeln im nachhinein maschinell kaum veränderbar oder gar erlernbar sind.

Bei der Verarbeitung natürlicher Sprache zeichnet sich in den letzten Jahren eine immer stärkere Tendenz zu den statistischen Ansätzen ab. Diese Techniken sind geprägt von der Überlegung, dass es möglich ist, Sprache statistisch zu erfassen. Anstatt ein Regelwerk zu erstellen, werden

mathematische Funktionen benutzt, um eine Regelmäßigkeit innerhalb der Sprache zu entdecken und daraus Rückschlüsse zu ziehen. So kann beispielsweise anhand der statistischen Verteilung von n-Grammen die Sprache eines Textes bestimmt werden, wenn zuvor entsprechende Zielsprachen auf die Häufigkeit des Auftretens von n-Grammen untersucht wurden. Vereinfacht dargestellt kann ein Text als englischsprachig klassifiziert werden, wenn in diesem das Trigramm "ing" häufig auftritt und zuvor bei der Untersuchung verschiedensprachiger Korpora "ing" als typisch englisches Trigramm befunden wurde. Man könnte sogar den "Hauptmann von Köpenick" anhand der Zahlreichen "dat" und "ick" als Berliner Dialekt klassifizieren, wenn man entsprechend große Mengen solcher Beispieltexte untersuchen kann, um eine statistische Regelmäßigkeit festzustellen.

Für den Einsatz in einem Personalisierungssystem eignen sich statistische Methoden wesentlich besser. Wie oben erwähnt wurde, ist ein regelbasiertes System nicht sehr flexibel, da das Regelwerk genau auf Sprache und Einsatzzweck zugeschnitten werden muss. Dies ist bei einem modularen Personalisierungssystem nicht möglich, da der Einsatzzweck stark variieren kann. Im Bereich der statistischen Sprachverarbeitung hingegen existieren Möglichkeiten der dynamischen Anpassung der Funktionen an die jeweiligen Sprachverhältnisse.

Abbildungen

Abbildung 1: Kriterien zur Auswahl von Personalisierungstechniken ............ 2-21 Abbildung 2: Aufbau eines komplexen regelbasierten Personalisierungssystems

........................................................................................................ 2-23 Abbildung 3: Produktempfehlung bei amazon.de (Screenshot) ................... 2-26 Abbildung 4: Modulare Struktur des Personalisierungssystems.................... 3-30 Abbildung 5: Typischer Fragebogen .......................................................... 3-32 Abbildung 6: Client-Server-Kommunikation - Anforderung einer Inhaltsseite 3-34 Abbildung 8: Strukturschema der Datenbank............................................. 3-50 Abbildung 9: Schema Nutzeraktion - Klick ................................................. 3-55 Abbildung 10: Klick und Standortwechsel .................................................. 3-57 Abbildung 11: Navigationsweg als Kette von Seitenanforderungen.............. 3-59 Abbildung 12: Anforderung einer Seite, Ablage im Cache und erneuter Aufruf.

Der zweite Aufruf von Seite 1 geschieht ohne erneute Seitenanforderung 3-

61

Abbildung 13: Verfälschte Navigationsdaten - Nutzer befindet sich scheinbar

gleichzeitig auf Seite 2 und Seite 3..................................................... 3-61 Abbildung 14: Rekonstruierter Weg nach Einfügen eines zusätzlichen

Seitenwechsels ................................................................................. 3-62 Abbildung 15: Durch Klick auf Link „Seite 2“ wird ein neues Browserfenster

geöffnet ........................................................................................... 3-63 Abbildung 16: Wechselseitige Navigation mit zwei Browserfenstern ............ 3-63 Abbildung 17: Bereinigung des Datenbestandes durch Einfügen eines

imaginären Seitenwechsels und Korrektur des zeitlichen Verlaufes (X steht

für die unbekannte Aufenthaltdauer auf Seite 5) ................................. 3-64 Abbildung 18: Bereinigung des Datenbestandes durch unabhängige Betrachtung

der Wegstränge und Korrektur des zeitlichen Verlaufs ......................... 3-65 Abbildung 19: Schritte bei der Verarbeitung von Textdaten ........................ 3-68 Abbildung 20: Strukturschema der Wortschatzdatenbank ........................... 3-78 Abbildung 21: Auszug aus einem Server-Logfile......................................... 3-86 Abbildung 22: Schnittmenge zwischen Nutzerwortschatz und Text als Messwert

für das vermutete Interesse eines Nutzers an einem nicht klassifizierten

Text ............................................................................................... 3-100 Abbildung 23: Berücksichtigung der Synonyme des Nutzerwortschatzes und des

Textes............................................................................................ 3-100

Abbildung 24: Ermittlung potentiell interessanter Bilder mittels kollaborativen

Filterns........................................................................................... 3-112 Abbildung 25: Visualisierung der Website-Struktur ................................... 3-115 Abbildung 26: Teilgraph einer Website mit angetragenen Nutzungsintensitäten

...................................................................................................... 3-116

Gleichungen

Gleichung 1: Korrelationskoeffizient nach Pearson ..................................... 2-27 Gleichung 2: Nutzungsintensität ............................................................... 3-55 Gleichung 3: Wahrscheinlichkeit für gemeinsames Auftreten zweier Wörter in

einem Satz ....................................................................................... 3-72 Gleichung 4: Hypothese bei einem Signifikanzniveau von 0.9 ..................... 3-72

Beispiele

Beispiel 1: Neighbourhood-Methode - Bestand der Bewertungsdaten

(Schulnoten) der Nutzer und berechnete Korrelationskoeffizienten

(gerundet)........................................................................................ 2-27 Beispiel 2: Einer statischen HTML-Datei kann ihre URL als Bezeichner

zugeordnet werden ........................................................................... 3-38 Beispiel 3: Einer skript-generierten Seite kann eine aus der URL und den

übermittelten Parametern (URL-/Post-Parameter) gebildete Zeichenkette

als Bezeichner zugeordnet werden ..................................................... 3-39 Beispiel 4: Explizite Vergabe eines Seitenbezeichners mit Hilfe von

Quelltextparametern ......................................................................... 3-40 Beispiel 5: Bildung des Bezeichners eines Aktionselementes (Link) aus der Ziel-

URL und dem Link-Text ..................................................................... 3-40 Beispiel 6: Für ein Formular kann der Bezeichner aus dem Attributbereich und

den Namen der Fomularfelder gebildet werden................................... 3-41 Beispiel 7: Anhängen des Seitenindentifikators und einer fortlaufenden

Nummerierung ermöglicht eindeutige Vergabe von Aktionselement-Bezeichnern...................................................................................... 3-41 Beispiel 8: Explizite Vergabe eines Bezeichners für ein Aktionselement durch

den Betreiber.................................................................................... 3-42 Beispiel 9: Definition einer funktionalen Einheit, bestehend aus mehreren

Aktionselementen ............................................................................. 3-43 Beispiel 10: Ausschluss eines Links durch Definition eines unbenannten Blocks3-

44

Beispiel 11: Formulareingaben eines Nutzers - aktive Textdaten ................. 3-44 Beispiel 12: HTML-Formular mit Nutzereingabe.......................................... 3-45

Beispiel 13: Parameterübermittlung durch CGI-Datenübertragung .............. 3-45 Beispiel 14: Spezifikation zu verarbeitender Eingabefelder.......................... 3-47 Beispiel 15: Durch die Anwendung bereitgestellte Texte - passive Textdaten...3-

48

Beispiel 16: Übermittlung von Ursprungsseiten-, Link- und Session-

Indentifikator als URL-Parameter ....................................................... 3-52 Beispiel 17: Übermittlung von Ursprungsseiten-, Link- und Session-

Indentifikator als versteckte Formularfelder ........................................ 3-52 Beispiel 18: Nutzungshäufigkeit und -intensität von zehn Aktionselementen 3-56 Beispiel 19: Beispiele für Nutzereingaben in einem Reiseportal ................... 3-66 Beispiel 20: Bedingungslose Segmentierung (Trennzeichen: Leerzeichen, Punkt)

........................................................................................................ 3-69 Beispiel 21: Bedingte Segmentierung (Trennzeichen: Leerzeichen, bedingtes

Trennzeichen: Punkt) ........................................................................ 3-69 Beispiel 22: Textanalyse bei Betrachtung eines Wortfensters ...................... 3-71 Beispiel 23: Explizite Spezifikation eines Textblocks im Seitenquelltext ........ 3-75 Beispiel 24: Beispieleinträge der Wortschatzdatenbank .............................. 3-79 Beispiel 25: Aufstellung möglicher Kriterien und deren Gewichtung für die

Beurteilung des Erfahrungslevels eines Nutzers................................... 3-82 Beispiel 26: Bestimmung eines Textblocks zur Verarbeitung ....................... 3-83 Beispiel 27: Berechnung eines Wortschatz - Text Beziehungswertes .......... 3-84 Beispiel 28: Ermittlung der Synonymgruppen für die Berechnung eines

Beziehungswertes auf Bedeutungsebene ............................................ 3-84 Beispiel 29: Berechnung eines Beziehungswertes auf Bedeutungsebene...... 3-85 Beispiel 30: Nutzungsschwerpunkt (räumlich)............................................ 3-87 Beispiel 31: Nutzungsschwerpunkt (zeitlich) .............................................. 3-87 Beispiel 32: Nutzungsschwerpunkt (räumlich/zeitlich) ................................ 3-88 Beispiel 33: Beeinflussung der Sichtbarkeit von Elementen in Abhängigkeit der

Besucherinteressen ........................................................................... 3-95 Beispiel 34: Quelltextbeispiel für die Beeinflussung der Sichtbarkeit von

Elementen in Abhängigkeit der Besucherinteressen ............................. 3-96 Beispiel 35: Personalisierte Anordnung von Elementen (hier: Links zu

Unterkategorien)............................................................................... 3-97 Beispiel 36: Quelltextbeispiel für das Anzeigen der drei meistgenutzten

Unterkategorien, bezogen auf einen Nutzer ........................................ 3-98 Beispiel 37: Quelltext nach dem Parsen..................................................... 3-99 Beispiel 38: Ranking von Textblöcken mittels dynamischen Wortschatzvergleichs

...................................................................................................... 3-101

Beispiel 39: Quelltextbeispiel für das Ranking von Textblöcken ................. 3-102 Beispiel 40: Hotlinks - Verknüpfungen zu den von dieser Seite aus am meisten

angesteuerten Zielen dieses Nutzers ................................................ 3-103 Beispiel 41: Spezifikation eines Verweises als Hotlink ............................... 3-103 Beispiel 42: Einbindung der drei meistgenutzten Hotlinks ......................... 3-104 Beispiel 43: Prefilling von Formularfeldern auf Basis der bisherigen

Nutzereingaben .............................................................................. 3-105 Beispiel 44: Implementierung eines Formular-Prefillings ........................... 3-105 Beispiel 45: Rechtschreibkontrolle anhand eines individuellen

Nutzerwortschatzes......................................................................... 3-106 Beispiel 46: Tippfehlererkennung unter Beachtung des Tastaturlayouts..... 3-107 Beispiel 47: Schreibfehlererkennung anhand phonetisch Ähnlichkeiten ...... 3-107 Beispiel 48: Überflüssige und fehlende Buchstaben .................................. 3-107 Beispiel 49: Tippfehler durch Buchstabendreher ...................................... 3-107 Beispiel 50: Auswahl der Inhalte nach Bewertung anhand des Nutzerprofils ....3-

109

Beispiel 51: Zusätzliche Informationen für fortgeschrittene Anwender....... 3-110 Beispiel 52: Anzeige von Zusatzinformationen für fortgeschrittene Nutzer . 3-111 Beispiel 53: Spezifikation eines Containers für die Elemente, deren

Nutzungsintensivität gemessen werden soll ...................................... 3-111 Beispiel 54: Inhaltsvorschläge unterstützt durch kollaboratives Filtern....... 3-113 Beispiel 55: Spezifikation eines Elementes ............................................... 3-114 Beispiel 56: Identifizierte Inhaltsseiten mit teilweise ortsbestimmenden

Parametern .................................................................................... 3-118 Beispiel 57: Liste von Funktionswörtern zufällig ausgewählter Sprachen.... 5-121 Beispiel 58: Beispiele deutscher Kollokationen ......................................... 5-122 Beispiel 59: Liste typischer Trigramme zufällig ausgewählter Sprachen ..... 5-122 Beispiel 60: Wort-Vektor Modell am Beispiel „Der kleine Prinz“ ................. 5-123 Beispiel 61: Kollokation-Vektor Modell am Beispiel „Der kleine Prinz“ ........ 5-124

Quellen, Referenzen und Verweise

Bernardo A. Huberman, Peter L. T. Pirolli, James E. Pitkow, Rajan M. Lukose (4/1998) “Strong Regularities in World Wide Web Surfing”, Science Vol.280 Bruhn, Manfred, Homburg, Christian (1999) „Handbuch

Kundenbindungsmanagement Grundlagen, Konzepte, Erfahrungen“ Craven, Mark, DiPasquo, Dan, Freitag, Dayne, McCallum, Andrew, Mitchell, Tom, Nigam, Kamal, Slattery, Sean (1998) “Learning to Extract Symbolic Knowledge from the World Wide Web”, Proceedings of 15th National Conference on Artifcial Intelligence

Erskine, Lewis E., Carter-Tod, David R. N. and Burton, John K. (1997) “Dialogical techniques for the design of web sites”, Academic Press Limited Good, N., Schafer, J.B., Konstan, J., Borchers, A., Sarwar, B., Herlocker, J., and Riedl, J. (1999) “Combining Collaborative Filtering with Personal Agents for Better Recommendations“, Proceedings of the 1999 Conference of the American Association of Artifical Intelligence (AAAI-99). pp. 439-446. Hanson (2000) „Principles of the Internet Marketing“ Herlocker, J., Konstan, J., and Riedl, J. (December 2-6, 2000) “Explaining Collaborative Filtering Recommendations”, In proceedings of ACM 2000 Conference on Computer Supported Cooperative Work, pp. 241-250. Justeson, Jonh S. and Katz, Slava M. (1995) “Technical terminology: some linguistic properties and an algirithm for identification in text”, Natural Language Engineering, 1:9-27

Li, Xiaobin, Szpakowicz, Stan and Matwin, Stan (2001) “A WordNet- Concordia based Algorithm for Word Sense Disambiguation”, University/University of Ottawa

Manning, Christopher D. and Schütze, Hinrich (2000) “Foundations Of Statistical Natural Language Processing”, MIT Press Miller, George A., Beckwith, Richard, Fellbaum, Christiane, Gross, Derek, and Miller, Katherine (1993) “Introduction to WordNet: An On-line Lexical Database”, Princeton University

Mladenic, Dunja (2001) “Machine learning for better Web browsing”, Dpt. of Intelligent Systems, J.Stefan Institute

O'Connor, M., Cosley, D., Konstan, J. A., & Riedl, J. (2001) “PolyLens: A Recommender System for Groups of Users”, In Proceedings of ECSCW 2001, pp. 199-218.

ODP - The Open Dictionary Project (http://dmoz.org) Pitkow, James E. (2001) “Summary of WWW Characterizations”, Xerox Palo Alto Research Center

Sarwar, B. M., Karypis, G., Konstan, J. A., and Riedl, J. (2000) "Application of Dimensionality Reduction in Recommender System - A Case Study". ACM WebKDD 2000 Web Mining for E-Commerce Workshop Sarwar, B. M., Karypis, G., Konstan, J. A., and Riedl, J. (May 2001) “Item-based collaborative filtering recommendation algorithms”, In Proceedings of the 10th International World Wide Web Conference (WWW10) Schafer, J.B., Konstan, J., and Riedl, J. (November 3-5, 1999) „Recommender Systems in E-Commerce“, Proceedings of the ACM Conference on Electronic Commerce.

Siegel, David (1998) „Web Site Design. Killer Web Sites der 3. Generation”, Markt u. Technik