Entwurf und Umsetzung einer Architektur zur kontextbasierten Dienstevermittlung

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1. Einleitung
1.1. Vorbemerkung
1.2. Motivation
1.3. Zielsetzung
1.4. Struktur

2. Grundlagen
2.1. Ubiquitous Computing
2.2. Service Discovery
2.3. Kontextbegriff
2.3.1. Was ist Kontext?
2.3.2. Kontext in der Informatik
2.3.3. Arten von Kontext
2.3.4. Context-Awareness
2.3.5. Kontextmodellierung

3. Existierende Ansätze und Architekturen
3.1. Beschreibung existierender Ansätze und Architekturen
3.1.1. Service Discovery
3.1.1.1. Traditionelle Service Discovery
3.1.1.2. Context-Aware Service Discovery
3.1.1.3. Ontology-Based Service Discovery
3.1.2. Kontextmodellierung
3.1.2.1. Key-Value Modelle
3.1.2.2. Markup Schema Modelle
3.1.2.3. Grafische Modelle
3.1.2.4. Objektorientierte Modelle
3.1.2.5. Logikbasierte Modelle
3.1.2.6. Ontologiebasierte Modelle
3.1.3. Context-Awareness
3.1.3.1. Frameworks
3.1.3.2. Anwendungen
3.2. Bewertung relevanter Architekturen

4. Realisierung
4.1. Gewählter Ansatz
4.2. Die Architektur - CASPAR
4.3. Beispielimplementierung
4.3.1. Kontextmodell
4.3.2. Service Discovery Protokoll
4.3.3. CASPAR Directory Service
4.3.4. CASPAR Web Service
4.3.5. CASPAR Client Applikation
4.4. Interaktion der Komponenten

5. Fazit
5.1. Ergebnisse
5.2. Ausblick

Anhang I: Beispiel-serviceResponse

Anhang II: Beispiel-specialOntology

Literaturverzeichnis

Abbildungsverzeichnis

Abb. 1: Entwicklungsprozess zum Ubiquitous Computing

Abb. 2: Entwicklung zum Ubiquitous Computing nach Strang

Abb. 3: Paradigmen des Ubiquitous Computing nach Diekmann / Hagenhoff

Abb. 4: Kontextbegriff nach Lieberman / Selker

Abb. 5: Anwendungsfälle nach Schilit / Adams / Want

Abb. 6: Beispiel einer UI Technik der „Proximate Selection“ nach Schilit / Adams / Want

Abb. 7: Jini Dienstvermittlung

Abb. 8: Aktiver und Passiver Discovery Prozess des SLP

Abb. 9: Die CBSeC Architektur

Abb. 10: Das Modell eines Context Brokers

Abb. 11: Drei Schichten der JCAF Runtime Infrastructure

Abb. 12: Synchrones Verfahren der Kontexterfassung im JCAF

Abb. 13: Architektur des Context Toolkits nach Dey / Abowd / Salber

Abb. 14: Der mobile ParcTab

Abb. 15: Prinzip des SmartCadie

Abb. 16: CASPAR Überblick

Abb. 17: Ausschnitt aus dem Kontextmodell

Abb. 18: Condition Struktur

Abb. 19: Challenge-Response Authentifizierungsverfahren

Abb. 20: Caspar im Hintergrund

Abb. 21: Zuweisen von Leistungsmerkmalen

Abb. 22: Nützliche Dienste gefunden

Abb. 23: Dienstinformationen und Werteauswahl

Abb. 24: Architektur Übersicht

Abb. 25: Das Meeting in Microsoft Outlook

Abb. 26: Aufruf der Fahrplanauskunft

Abb. 27: Sequenzdiagramm

Tabellenverzeichnis

Tab. 1: Bewertung verschiedener Kontextmodellierungsansätze nach Strang / Linnhoff-Popien

Tab. 2: Bewertung relevanter Architekturen

Tab. 3: Geltungsbereich der Anforderungen

Tab. 4: Anforderungsbewertung des Kontextmodells

Tab. 5: Anforderungsbewertung des Protokolls

Tab. 6: Anforderungsbewertung des Directory Service

Tab. 7: Anforderungsbewertung des Kontextmanagers

Tab. 8: Anforderungsbewertung der Client Applikation

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1. Einleitung

1.1. Vorbemerkung

Angetrieben durch die rasche Entwicklung in der Computerindustrie gibt es immer mehr Zukunftsvisionen, die schon bald realisierbar sein könnten. Bereits 1991 beschrieb Mark Weiser seine Vision des Ubiquitous Computing¹, in der Computer allgegenwärtig sind, und sie nicht mehr als Fremdkörper wahrgenommen werden. Die Bedienung muss so intuitiv und einfach sein, dass jeder, auch ohne Vorkenntnisse, die Möglichkeit hat, die Vorteile, die die elektronische Datenverarbeitung bietet, zu nutzen. Dabei werden nicht mehr PCs mit ihren vielfältigen Anwendungsbereichen eingesetzt, sondern kleine, hoch spezialisierte Geräte, die intelligent vernetzt sind. Das erhöht die Flexibilität und maximiert die Leistungsfähigkeit an dem Ort, an dem sie gebraucht wird. Grundsätzlich lässt sich der Entwicklungsprozess zum Ubiquitous Computing in drei Phasen einteilen (s. Abb. 1). Am Anfang der Computernutzung gab es noch zentrale, leistungsfähige Mainframes, die ihre Ressourcen einer Vielzahl von Benutzern über individuelle Terminals zur Verfügung stellten (Mainframe-Ära).

Abb. 1: Entwicklungsprozess zum Ubiquitous Computing

Abbildung in dieser Leseprobe nicht enthalten

In den 80er Jahren begann der Personal Computer (PC) dann seinen Siegeszug, und schon bald konnte ein Benutzer auch alle Ressourcen eines einzelnen PC Systems nutzen (PC-Ära). In der letzten Phase dieses Entwicklungsprozesses sind einem Benutzer viele verschiedene Computersysteme zuzuordnen. All diese Geräte stehen ihm zur Verfügung, um bestimmte Aufgaben zu lösen (Ubiquitous- Computing-Ära). Der Computer verschwindet allmählich und wird zum Alltagsgegenstand.

Ebenfalls in diese Richtung geht der Begriff des Pervasive Computing, welcher von der Industrie geprägt wird. Er beschreibt die allesdurchdringende Vernetzung des Alltags durch den Einsatz intelligenter Geräte mit dem Ziel, die allgegenwärtige Informationsverarbeitung „im Rahmen von Electronic-Commerce-Szenarien und Web-basierten Geschäftsprozessen nutzbar zu machen“². Bereits heute findet Pervasive Computing Anwendung in verschiedenen Bereichen. Hierbei kommen häufig RFID (Radio Frequency Identification) Tags zum Einsatz. Ein RFID Reader erzeugt ein elektromagnetisches Feld, welches in der Antenne des Tags einen Induktionsstrom entstehen lässt. Dieser Strom reicht für das Tag aus, sich selbst zu aktivieren und die vom Reader abgefragten Daten zu senden. So ist ein Lesen der auf dem Tag gespeicherten Daten ohne Sichtkontakt möglich. Zum Beispiel können RFID Tags eingesetzt werden, um bestimmte Geschäftsprozesse wie zum Beispiel Warenein- und -ausgang abzuwickeln³. Die Ablösung der herkömmlichen Barcodes durch RFID Tags kann Aufschluss über das Einkaufsverhalten geben und die Kassiererin im Supermarkt überflüssig werden lassen. Lou Gerstner, ehemaliger IBM Aufsichtsratvorsitzender, umschrieb 1997 das Szenario als „a billion people interacting with a million e-businesses with a trillion intelligent devices interconnected.“

Damit diese Systeme möglichst ohne explizite Bedienung auskommen, ist es nötig, sie über ihre Umgebung Bescheid wissen zu lassen. Der aktuelle Zustand der Umgebung und allem, was für das System relevant sein könnte, wird im Allgemeinen als Kontext bezeichnet. Somit ergibt sich als eine von mehreren Anforderungen für Pervasive oder Ubiquitous Computing Systeme eine so genannte Context-Awareness. Die Systeme werden sich ihrer Umgebung „bewusst“.

1.2. Motivation

Im Zuge der stetigen Zunahme an verfügbaren Informationen im Internet, wird es immer wichtiger, diese gezielt nutzen zu können. Der reine passive Informationsabruf reicht nicht mehr aus und lässt die Entwicklung in verschiedene Richtungen voranschreiten.

Eine dieser Richtungen ist das so genannte Web 2.0, unter dessen Namen Techniken zusammengefasst werden, die das Internet nicht mehr nur als reine Informationsquelle, sondern als Plattform verstehen lassen. Wurde früher eine einfache persönliche Internetseite erstellt, so ist es heute ein Blog, mit dem man seine letzten Urlaubserlebnisse der Welt zugänglich macht. Bilder und Videos werden zudem im Online-Photoalbum präsentiert oder per Podcast veröffentlicht. Selbst für komplexe Anwendungen wie Microsoft Word oder Microsoft Excel gibt es ein Pendant mit ähnlichem Funktionsumfang als Web 2.0 Anwendung im Internet⁴.

Ebenfalls aus dieser Entwicklung hervorgegangen ist das „Semantic Web“. Das nach einer Idee von Tim Berners-Lee, Gründer und Direktor des World Wide Web Consortiums (W3C⁵ ), entstandene Konzept wurde vom W3C erarbeitet und beschreibt eine Erweiterung des World Wide Web, wonach den Inhalten im Internet eine formale Beschreibung ihrer Bedeutung hinzugefügt wird. Diese Beschreibung soll maschinenlesbar und somit durch Computer verarbeitbar sein. Das Web wandelt sich also von einem reinen Web von Menschen für Menschen zu einem Web von Menschen für Mensch und Maschine. So ist es denkbar, dass eine Anfrage wie: “Wie viele Tore hat Fußballer X im Jahre 1998 geschossen?“ in Zukunft direkt von einer Suchmaschine beantwortet werden kann, die wie Swoogle⁶ darauf ausgerichtet ist, die erwähnten Beschreibungsdaten zu verarbeiten.

In eine weitere Entwicklungsrichtung gehen Web Services. Ihr Ziel ist es die Interoperabilität zwischen Maschinen zu ermöglichen⁷. Softwaresysteme stellen ihre Funktionalitäten anderen Softwaresystemen zur Verfügung. Dazu wird ein standardisierter Nachrichtenaustausch eingesetzt. Daher wird oft behauptet, dass Web Services für Rechner das sind, was Webseiten für den Menschen sind. Die im Jahr 2002 von IBM, BEA und Microsoft veröffentlichte Business Process Execution Language (BPEL) erweitert den Anwendungsbereich von Web Services und erlaubt die Beschreibung von Geschäftsprozessen, deren einzelne Aktivitäten als Web Services implementiert sind. Man nennt diesen Vorgang Web Service Orchestrierung. Die Beschreibung der Orchestrierung wird ebenfalls als Web Service bereitgestellt und ermöglicht so eine einfache Abwicklung des beschriebenen Geschäftsprozesses.

Schon jetzt ist erkennbar, dass diese Entwicklungen auf der einen Seite zwar ihre positiven Effekte haben, doch zugleich das Informations- und Serviceangebot ebenfalls größer werden lassen. Viele der vorhandenen Angebote bleiben unbeachtet und verlieren damit ihren Nutzen. Zwar könnte der Anwender den einen oder anderen Service gebrauchen, um sein Ziel zu erreichen, doch muss er ihn dafür erst einmal finden.

1.3. Zielsetzung

Das Ziel dieser Arbeit ist es, zu untersuchen, inwieweit ein Auffinden von Diensten (Service Discovery) in Abhängigkeit der Situation und der Absichten des Nutzers, also eines gewissen Kontextes, möglich ist. Wenn dieser Prozess maßgeblich vereinfacht und das Ergebnis verbessert werden kann, ist eine gute Grundlage für die Unterstützung des Benutzers geschaffen. Heutzutage ist es nämlich nicht mehr die Leistungsfähigkeit des Computers, der den Engpass bei der Entwicklung von Systemen darstellt, sondern die des Menschen⁸. Eine zu entwickelnde Architektur und dessen Umsetzung in einer Beispielimplementierung sollen die Möglichkeiten aufzeigen, und den Benutzer in die Lage versetzen, sein Ziel idealerweise mit einem Klick zu erreichen.

1.4. Struktur

In Kap. 2 werden zunächst grundlegende Begriffe und Definitionen erklärt, die im Rahmen dieser Arbeit immer wieder auftauchen werden. Es soll erörtert werden, wie Kontext bisher im Rahmen von kontextbasierten Anwendungen definiert wurde, und wie Kontext für die Erarbeitung dieser Diplomarbeit definiert sein soll. Kap. 3 gibt einen Überblick über bestehende Ansätze und Architekturen in verschiedenen, diese Arbeit betreffenden Gebieten, und stellt heraus, welche Anforderungen bei der Realisierung beachtet werden sollten. Eine Bewertung der vorgestellten Systeme hinsichtlich dieser Anforderungen stellt den Abschluss des dritten Kapitels dar. Der gewählte Ansatz, die entwickelte Architektur sowie dessen Umsetzung in Form einer Beispielimplementierung werden im Kapitel 4 beschrieben. Abschließend folgen in Kapitel 5 eine zusammenfassende Betrachtung der Ergebnisse sowie ein Ausblick.

2. Grundlagen

2.1. Ubiquitous Computing

Das Forschungsgebiet des Ubiquitous Computing entstand ursprünglich aus früheren Forschungsgebieten. So bildet eine ganze Kette, ausgehend vom Centralized Computing, den Weg zum Ubiquitous Computing. Die Erweiterung der jeweiligen bestehenden Forschungsgebiete um zusätzliche Aspekte führte zu neuen Gebieten mit neuen Bezeichnungen. Das Centralized Computing beschäftigte sich noch mit der Entwicklung zentralisierter Systeme, die ihre Ressourcen über Terminals zur Verfügung stellten. Die Einführung und der Erfolg des Personal Computers brachte die Erweiterung um Aspekte wie verteilte Dateisysteme und führte zum Forschungsgebiet des Distributed Computings.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: Entwicklung zum Ubiquitous Computing nach Strang

Darauf folgte die Verbreitung mobiler Geräte, die zu immer mehr Leistung fähig waren. Für die Bezeichnung der Forschung in dieser Richtung wurde der Begriff Mobile Computing genutzt, welcher die Erweiterung des Distributed Computings um mobile Aspekte beschreibt. Hierzu gehören unter anderem mobile Netzwerke und mobiler Datenzugriff. Den letzten Schritt bildet die Erweiterung um die Aspekte des Ad-hoc Networkings, der intelligenten Geräte und des Kontextbewusstseins. Dieses Forschungsgebiet ist heute als Ubiquitous Computing bekannt. Im Unterschied zum Mobile Computing können Dienste und Anwendungen Informationen aus ihrer Umgebung beziehen und sich so an diese anpassen. Eine Übersicht über den Entwicklungsablauf gibt Strang⁹ (s. Abb. 2). Den Begriff des Ubiquitous Computing beschrieb Mark Weiser bereits 1991¹⁰. Im Xerox Palo Alto Research Center (PARC) machte man sich Gedanken, wie sich der Computer in der nächsten Zeit entwickeln würde, und wie er den Menschen unterstützen könnte. Sämtliche Geräte, so genannte „Smarte Dinge“, sind permanent vernetzt und tauschen selbstständig Informationen aus, die sie mit ihren eingebetteten Sensoren aufgenommen haben. Das Internet, welches heute bereits fast alle Computer miteinander verbindet, breitet sich weiter aus, und vernetzt alltägliche Dinge zu einem „Internet der Dinge“¹¹. Nicht mehr der PC mit seinen vielfältigen Fähigkeiten, sondern viele kleine, spezialisierte Computer integrieren sich in das alltägliche Leben und unterstützen den Benutzer. Die Nutzung eines PC erfordert nach Weiser eine viel zu große Aufmerksamkeit des Anwenders und wird daher als störend empfunden. Deshalb sollten die informationsverarbeitenden Geräte „verschwinden“, ihre Fähigkeiten aber permanent verfügbar sein. Sie sollen allgegenwärtig werden. Verglichen mit dem Gebiet der Virtual Reality beschreibt das Ubiquitous Computing genau den entgegengesetzten Weg. Nicht die Welt wird in den Computer gebracht, sondern der Computer wird in die Welt gebracht¹². Um das Problem der heutigen Arbeit mit Computern zu verdeutlichen, verglich Weiser¹³ den Vorgang mit einem Waldspaziergang. Trotz der größeren Menge an Informationen, die uns bei einem solchen Spaziergang überflutet, wird er als entspannend empfunden. Das Arbeiten am Computer hingegen nicht. Diesen Unterschied soll das Ubiquitous Computing minimieren, indem es durch das Verschwinden der Computer das Arbeiten mit ihnen ebenfalls entspannend wirken lässt.

Weiser und seine Kollegen waren überzeugt, dass ihre Vision schon bald Realität werden würde:

„My colleagues and I at PARC believe that what we call ubiquitous computing will gradually emerge as the dominant mode of computer access over the next twenty years.”¹⁴

Wie es scheint, sind dank der Entwicklung in der Mikroelektronik die Grundsteine dafür gelegt. Immer kleinere Prozessoren und Sensoren lassen sich zu immer niedrigeren Preisen herstellen. Der Integration dieser Technik in die Umwelt steht grundsätzlich nichts mehr im Wege.

Auf Seiten der Software gibt es verschiedene Anforderungen und Grundsätze die für Ubiquitous Computing Systeme formuliert werden. Diekmann / Hagenhoff¹⁵ nennen vier Paradigmen, die bei der Umsetzung solcher System e beachtet werden sollten:

- Dezentralisierung: Aufgaben werden auf viele kleine Geräte verteilt. Sämtliche Entscheidungen werden dezentral getroffen und beruhen auf Informationen, die ebenfalls dezentral vorliegen. Die Synchronisation und Aktualisierung der vorhandenen Informationen bildet damit eine große Herausforderung im Ubiquitous Computing.
- Diversifikation: Die verschiedenen Geräte in einer Ubiquitous Computing Umgebung besitzen eine explizit abgegrenzte Funktionalität und stehen somit im Gegensatz zu heutigen Computern, die eine Universalplattform für verschiedenste Funktionalitäten bieten, die nur durch den Einsatz bestimmter Software eingegrenzt werden.
- Konnektivit ä t: Damit die intelligenten Geräte zusammen arbeiten können, ist die Konnektivität dieser Geräte eine Voraussetzung, welche wiederum Protokolle erfordert, die die Kommunikation unter den Geräten einheitlich regeln. Ebenso ist die darunter liegende Netzwerkinfrastruktur ein wichtiger Bestandteil hinsichtlich der Konnektivität der Geräte.
- Simplizit ä t: Da die Anzahl der verfügbaren Computer pro Benutzer im Ubiquitous Computing stark ansteigen wird, muss die Aufmerksamkeit, die ein Benutzer einem einzelnen Computer zu seiner Bedienung entgegen bringen muss, stark sinken. Eine leichte Bedienbarkeit ist eine Grundvoraussetzung für die wirkungsvolle Unterstützung des Benutzers. Intuitiv, ohne jegliche Vorkenntnisse und Schulungen, soll das Ziel erreichbar sein. Nur so ist die Akzeptanz von Geräten und Anwendungen im Alltag zu erwarten.

Um die Dezentralisierung umzusetzen, kann auf Ergebnisse der Forschung im Bereich der Verteilten Systeme zurückgegriffen werden. Hier sind bereits Konzepte zur Funktions-, Daten- und Lastverteilung entstanden. Die Diversifikation der Geräte fördert zugleich den Punkt der einfachen Bedienung. Spezialisierte Geräte lassen oft eine viel intuitivere Bedienung zu als typische Computer es heutzutage tun. So kann beispielsweise jeder ein Telefon bedienen, die erfolgreiche Initiierung eines Gesprächs über Internettelephonie ist aber eher erfahreneren Anwendern vorbehalten¹⁶. Eine grundsätzliche Konnektivit ä t ist heutzutage durch die Verbreitung des Internet gegeben. Des Weiteren sind im Bereich Ubiquitous Computing vor allem drahtlose Netzwerktechniken von Bedeutung, da sie durch ihren geringen Installationsaufwand die spontane Vernetzung möglich werden lassen. Ansätze zur Umsetzung der Simplizit ä t lassen sich bei der Entwicklung von „Embedded Devices“ und neuen Mensch-Maschine Interaktionsformen finden. Ein „Embedded Device“ ist ein Computer-System, „das einen Gegenstand steuert, von dem es beherbergt wird“¹⁷. Außerdem erweitert es dessen Fähigkeiten zur Sensorik, Wahrnehmung und Kommunikation. Neue Mensch-Maschine Interaktionsformen sind zum Beispiel Sprachsteuerung, Handschriftenerkennung oder auch Steuerung durch Gedanken, indem Hirnströme ausgewertet und in verschiedene Aktionen umgesetzt werden. Sie versprechen einfache Bedienungsmöglichkeiten für zukünftige Computer-Systeme.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3: Paradigmen des Ubiquitous Computing nach Diekmann / Hagenhoff

Fragen, die in Verbindung mit Ubiquitous Computing immer lauter werden, sind die zur Privatsphäre und zum Datenschutz. Das Institut für Wirtschaftsinformatik an der Berliner Humboldt Universität fertigt im Auftrag des Bundesministeriums für Bildung und Forschung eine Studie zu diesem Thema unter dem Namen TAUCIS (Technikfolgen-Abschätzung Ubiquitäres Computing und Informationelle Selbstbestimmung) an. Sie soll zeigen, welche Auswirkungen das Ubiquitous Computing in diesem Bereich haben könnte. Hauptaugenmerk liegt dabei auf der RFID-Technologie, welche die Identifikation und Bewegungsverfolgung sämtlicher Gegenstände, unter anderem auch des neuen Reisepasses, der mit RFID Tags ausgestattet wird, ermöglicht. Dies erlaubt ganz neue Wege, das Verhalten von Menschen über die Objekte, die sie bei sich haben, zu analysieren. Wie stark Benutzer sich dadurch kontrolliert fühlen, oder ob sie die neuen Möglichkeiten schätzen, sollte die Online Umfrage der Zeitung „Die Zeit“ herausstellen¹⁸. Eine Erkenntnis aus dieser Umfrage ist, dass die Befragten ungern die Kontrolle über die Anwendung verlieren. Ebenso hat das Vertrauen in das System und dessen Betreiber eine Auswirkung auf die Akzeptanz desselben.

2.2. Service Discovery

Wenn die Dienstnutzung in Zukunft einen zentralen Teil der Arbeit mit Computern darstellt, ist es nötig, diese Dienste vorher zu finden. Den Prozess der Dienstevermittlung, der dazu initiiert wird, bezeichnet man als Service Discovery. Wichtige Begriffe im Rahmen von Dienstvermittlungsprotokollen sind Dienst, Dienstanbieter, Dienstbeschreibung sowie Lookup- und Discovery-Prozess, deren Bedeutungen an dieser Stelle nach Samulowitz¹⁹ beschrieben werden.

Ein Dienst ist ein beliebiger Netzwerkdienst, der eine definierte Funktionalität zur Verfügung stellt. Diese Funktionalität und die dazugehörige Schnittstelle werden in der Dienstbeschreibung spezifiziert. „Der Dienstanbieter bezeichnet die Ressource oder das Gerät, welches einen Dienst ausführt“²⁰. Es kann sich dabei also um einen gewöhnlichen Computer handeln, aber auch spezialisierte Geräte, wie Drucker oder Digitalkameras, die ihre Funktionalitäten zur Verfügung stellen, gelten als Dienstanbieter. Ein einzelner Dienstanbieter ist hierbei nicht auf die Bereitstellung eines einzigen Dienstes beschränkt. Ein Drucker beispielsweise kann sowohl Druck- als auch Faxaufträge verarbeiten und somit mehrere Dienste zur Verfügung stellen.

McGrath²¹ unterscheidet die Begriffe Lookup und Discovery auf folgende Art und Weise:

Lookup bezeichnet den Prozess des Lokalisierens einer Ressource, eines Objektes oder Ähnlichem. Dazu wird entweder der Name, die Adresse oder ein anderes Matching-Kriterium verwendet. Dieser Prozess ist passiv, da er von einem Dienstnachfrager initiiert werden muss. Über einen zentralen Verzeichnisdienst, dessen Existenz in diesem Szenario unabdingbar ist, wird die Anfrage beantwortet.

Discovery meint einen spontaneren Ansatz, bei dem nicht nur ein zentraler Verzeichnisdienst, sondern viele Netzwerkressourcen andere Netzwerkressourcen entdecken und sich selbst im Netzwerk präsentieren und veröffentlichen. Ziel solcher Discovery-Protokolle ist es, Netzwerke einfacher aufbauen und nutzen zu können.

Im Rahmen dieser Arbeit wird auch das Finden des Verzeichnisdienstes als Discovery-Prozess angesehen und die von McGrath beschriebene Differenzierung vernachlässigt.

2.3. Kontextbegriff

2.3.1. Was ist Kontext?

Der Begriff Kontext kommt aus dem Lateinischen und bedeutet laut Brockhaus Enzyklopädie²² zunächst einmal nur „Zusammenhang“ oder „Umfeld“. Wenn ein Objekt also in einem gewissen Kontext steht, heißt das nur soviel wie, es besteht ein Zusammenhang zwischen diesem Objekt und einem weiteren Objekt. Das Merriam-Webster Online Dictionary²³ geht etwas weiter und liefert für Kontext die Definition: „the interrelated conditions in which something exists or occurs“. Diese wechselseitigen Beziehungen werden zum Beispiel sichtbar, wenn man einen Satz als Kontext für ein Wort betrachtet. Das Wort erhält durch den Satz eine bestimmte Bedeutung, sowie auch der Satz durch das Wort eine bestimmte Bedeutung bekommt.

2.3.2. Kontext in der Informatik

Für die Benutzung von Kontext in der Informatik sind diese Definitionen von Kontext aber nicht ausreichend und haben daher viele Entwickler auf diesem Gebiet dazu verleitet, eine neue Definition für Kontext im Bereich der Informatik zu entwickeln.

Schilit / Theimer²⁴ waren 1994 die ersten, die sich dieser Thematik widmeten und eine Aufzählung möglicher zum Kontext gehörender Informationstypen aufstellten. Für sie waren dies Informationen über den Aufenthaltsort sowie die Identität von Personen und Objekten in der näheren Umgebung und die Änderung dieser Informationen über die Zeit. Diesen Ansatz der einfachen Auflistung der Informationstypen, die zum Kontext gehören können, verfolgten am Anfang mehrere Entwickler²⁵, doch führt er zu Schwierigkeiten bei der Umsetzung in einer Anwendung. Bei Informationstypen, die nicht in der Aufzählung vorkommen, gibt es keine Möglichkeit sicher zu entscheiden, ob es sich um relevante oder irrelevante Informationen bezüglich des Kontextes handelt²⁶. Wie soll die Anwendung entscheiden ob die Temperatur möglicherweise eine hilfreiche Information sei? Noch im selben Jahr identifizierten Schilit / Adams / Want²⁷ zusätzliche Arten von Informationen als relevante Kontextelemente und unterteilten die verschiedenen Informationstypen in drei Kategorien:

- Computing context - Netzwerkverbindungsfähigkeit, Kommunikationskosten, Bandbreite, Ressourcen in der näheren Umgebung
- User context - Profil, Aufenthaltsort, benachbarte Personen, soziale Situation (Meeting, Mittagessen etc.)
- Physical context - Lichtverhältnisse, Umgebungslautstärke, Verkehrsituation, Temperatur

Chen / Kotz²⁸ schlugen die Definition des „Time context“ als vierte Kategorie vor, da Zeit schwer in einer der anderen Kategorien untergebracht werden konnte. Dennoch besteht weiterhin das Problem der Umsetzung, da es sich immer noch um eine reine Auflistung der Informationstypen handelt. Auch der Versuch, die wichtigen Aspekte von Kontext etwas abstrakter als „where you are, who you are with, and what resources are nearby“²⁹ zu formulieren, reicht für eine vollständige Fassung des Begriffs nicht aus.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4: Kontextbegriff nach Lieberman / Selker

Liebermann / Selker³⁰ gingen in die technologisch orientierte Richtung und behaupteten „Context can be considered to be everything that affects the computation except the explicit input and output” (s. Abb. 4). Damit abstrahierten sie von einzelnen Informationstypen und betrachteten eher die Verarbeitung, also den Einfluss auf das System, als kennzeichnendes Merkmal von Kontextinformationen.

Die bisher am weitesten verbreitete Definition von Kontext lieferten Dey / Abowd³¹:

“Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves.”

Ihre Definition lässt sämtliche Informationen als möglichen Kontext zu. Dazu gehören ebenso explizit eingegebene Werte, wie auch implizit vom System ermittelte Informationen. Sie wählten diesen Ansatz, nachdem sie vorherige Definitionen analysierten, und ebenfalls die bereits genannten Schwächen feststellten. Diese abstrakte Sichtweise soll auch den Kontextbegriff im Rahmen dieser Arbeit definieren. Als Kontextinformation wird nachfolgend ein einzelnes Element, welches eine bestimmte Information repräsentiert, verstanden.

2.3.3. Arten von Kontext

Zur Differenzierung des Kontextbegriffes werden verschiedene Arten von Kontext auf verschiedenen Abstraktionsebenen unterschieden.

Versucht man zunächst den Kontext hierarchisch zu strukturieren, entsteht die Aufteilung des Kontextes in Primär- und Sekundärkontext. Schilit / Adams / Want³² beschrieben in ihrer Arbeit den Primärkontext als “where you are, who you are with, and what resources are nearby”. Dey / Abowd³³ zählen Ort, Identität, Zeit und Aktivität zu den primären Kontexttypen und orientieren sich hierbei an Ryan / Pascoe / Morse³⁴, die mit Umgebung anstelle von Aktivität arbeiteten. Doch da Umgebung als Synonym für Kontext verstanden werden kann, entschieden sich Dey / Abowd für den Begriff Aktivität, um die Definition so eindeutig wie möglich zu halten. Ausgehend von dieser Beschreibung des Primärkontextes wird der Sekundärkontext als solche Information angesehen, die sich mithilfe des Primärkontextes abfragen lässt. Ist zum Beispiel die Identität einer Entität bekannt, so können weitere Informationen wie Telefonnummer, E-Mail Adresse oder Geburtsdatum in Erfahrung gebracht werden. Außerdem kann aus dem Ort einer Entität geschlossen werden, welche anderen Entitäten sich in der Nähe befinden. Der Primärkontext stellt also einen Index dar, über den sowohl der Sekundärkontext derselben Entität abgefragt werden kann, wie auch der Primärkontext von in Beziehung stehenden Entitäten. Durch die Unterscheidung zwischen Primär- und Sekundärkontext wird also nicht nur die Häufigkeit der Verwendung impliziert, sondern auch die Abhängigkeiten der verschiedenen Kontextelemente zueinander.

Auf einer weiteren Abstraktionsebene wird Kontext nach der Art seiner Erfassung unterschieden. Man spricht von so genannten High-Level und Low-Level Kontextelementen. Die Low-Level Kontextdaten werden dabei direkt durch Sensoren bezogen. Zu ihnen gehören Angaben über Lichtverhältnisse, Lautstärke, Temperatur oder auch die Zeit, die durch die Systemzeit relativ leicht erfassbar ist. Zur besseren Differenzierung machten Schmidt / Beigl / Gellersen einen Unterschied zwischen logischen und physikalischen Sensoren. Die physikalischen Sensoren messen physikalische Werte aus der Umgebung (z.B. Temperatur, Luftdruck, Lichtverhältnisse). Die Informationen, die direkt vom Hostsystem geliefert werden können (z.B. Zeit, Funkzelle) werden als logische Sensoren bezeichnet. Die Zeit betreffend, kann es für kontextsensitive Systeme durchaus noch interessant sein, zu wissen, welcher Wochentag ist, welches die aktuelle Jahreszeit ist oder ob es Arbeitszeit oder Freizeit ist. Diese Information geht dann schon in den Bereich der High-Level Kontextelemente. Solche umfassen nämlich Daten, die nicht direkt aus Sensoren bezogen werden können. So ist zum Beispiel aus dem Kalendereintrag und der aktuellen Uhrzeit folgerbar, dass der Benutzer in einem Meeting ist. Aus verschiedenen vorhandenen Elementen können also weitere Informationen gezogen werden, die nicht explizit in den Kontext eingeflossen sind.

2.3.4. Context-Awareness

Generell heißt context-aware so viel wie: „sich dem Kontext bewusst“. Dass die Meinungen darüber, was context-aware im Zusammenhang mit Software bedeutet, auseinander gehen, lässt sich schon an der Vielzahl benutzter Begriffe für die Beschreibung von Context-Awareness in früheren Arbeiten erkennen. Darunter fallen adaptive³⁵, reactive³⁶, responsive³⁷, situated³⁸, context-sensitive³⁹ und environment-directed⁴⁰. Im weiteren Verlauf dieser Arbeit ist context-aware gleichzusetzen mit „kontextbasiert“ oder „kontextsensitiv“. Eine kontextsensitive Applikation hat also zumindest Kontextinformationen zur Verfügung. Viele Forscher bezeichnen eine Anwendung als context-aware, wenn sie ihr Verhalten an den aktuellen Kontext anpasst. Doch hinsichtlich der meisten bestehenden kontextbasierten Applikationen ist diese Definition zu scharf formuliert. Eine Anwendung, die den erfassten Kontext nur auf dem Display darstellt, ändert zwar nicht ihr Verhalten oder passt es an, aber kann dennoch als kontextsensitiv bezeichnet werden. Auch wird oft behauptet, dass die genutzten Kontextinformationen „von Sensoren erfasst und der Anwendung zur Verfügung gestellt werden.“⁴¹ Die Beschaffung und Bereitstellung der Kontextinformationen kann aber auf verschiedensten Wegen realisiert werden. Eine abstraktere Definition für Context-Awareness fanden Dey / Abowd⁴²:

“A system is context-aware if it uses context to provide relevant information and/or services to the user, where relevancy depends on the user’s task.”

Demnach ist eine Anwendung kontextbasiert, wenn sie den Kontext benutzt, um auszumachen, welche Informationen oder Dienste für den Benutzer relevant sind und ihm diese präsentiert. Diese Definition soll auch die Grundlage für den Begriff von Context-Awareness im Rahmen dieser Arbeit bilden.

Die Nutzung der Kontextinformationen, um verschiedene Aktivitäten auszuführen, bezeichnet man als Kontextadaptivit ä t ⁴³. Eine kontextadaptive Anwendung passt sich implizit der Situation eines Benutzers an. Der Sinn einer solchen Anpassung ergibt sich aus der Möglichkeit, die Bedienung eines Systems auf diese Weise maßgeblich zu vereinfachen. Bereits in frühen Ansätzen des Ubiquitous⁴⁴ sowie Wearable⁴⁵ Computings spielte der Kontextbegriff eine große Rolle. Denn gerade in diesen Bereichen ist die Mobilität des Benutzers ein ausschlaggebender Faktor für das Verhalten des Systems. Die ständige Änderung der Umgebung des Benutzers, und somit die Änderung des Kontextes, lassen ein Verlangen nach kontextadaptiven Anwendungen laut werden.

Die Nutzung der Kontextinformationen teilen Schilit Anwendungsfälle auf:

- Proximate selection
- Automatic contextual reconfiguration ? Contextual commands
- Context-triggered actions

/ Adams / Want⁴⁶ in vier Diese vier Fälle können in zwei Dimensionen unterschieden werden. Zum einen nach manuell oder automatisch ausgelösten Operationen, und zum anderen nach aktions- oder datenbezogenen Operationen (vgl. Abb. 5).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 5: Anwendungsfälle nach Schilit / Adams / Want

Die Proximate selection beschreibt die Anzeige bestimmter kontextbezogener Daten nach Anforderung durch den Benutzer. Hierzu gehört zum Beispiel die Anzeige der Namen von Objekten in der unmittelbaren Umgebung des Benutzers (s. Abb. 6).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 6: Beispiel einer UI Technik der „Proximate Selection“ nach Schilit / Adams / Want

Mit Automatic contextual reconfiguration wird der Vorgang des automatischen Herstellens einer Verbindung zu einer bestimmten Ressource basierend auf Kontextinformationen beschrieben. Beispiel hierfür ist die Bereitstellung eines Druckers bei Betreten des Raumes in dem der Drucker sich befindet.

Kontextbezogene Aktionen, die aber erst vom Benutzer nitiiert werden müssen, gehören dem Bereich der Contextual commands an. Mithilfe dieses Konzeptes kann einerseits das kontextbezogene Anbieten von Diensten und andererseits die kontextbezogene Anpassung der Ausführung von Diensten verwirklicht werden.

Schließlich bezeichnen Context-triggered actions Operationen, die völlig autonom in Abhängigkeit des Auftretens eines bestimmten Kontextes ausgeführt werden. Bei Schilit / Adams / Want⁴⁷ werden diese Aktionen mit einfachen If-Then Regeln spezifiziert.

Zu einer ähnlichen, etwas vereinfachten Klassifizierung kontextadaptiver Anwendungen nach der Art ihrer Verhaltensanpassung kommen Rothermel / Bauer / Becker⁴⁸. Sie unterscheiden zwischen kontextbezogener Selektion, kontextbezogener Pr ä sentation und kontextbezogener Aktion. Die Dimension der Ausführungsinitiierung (automatisch / manuell) bleibt außen vor. Demnach ist kontextbezogene Selektion die Auswahl von Diensten und Informationen unter Zuhilfenahme der vorhandenen Kontextinformationen. Oft wird hierbei die Relevanz eines Dienstes nach seinem Ort bzw. der Nähe zum Benutzer bestimmt. Als primäre Kontextinformationen fließen also meist Ort, Identität und Zeit in die Auswahl mit ein. Persönliche Präferenzen des Benutzers können ebenfalls als Sekundärkontext berücksichtigt werden. Wenn sich die Darstellung einer Anwendung in Abhängigkeit des Kontextes verändert, spricht man von kontextbezogener Pr ä sentation. Ein Navigationssystem könnte zum Beispiel basierend auf der Information über die Geschwindigkeit des Fahrzeuges entscheiden, ob es den Fahrer per Sprachausgabe über die zu fahrende Strecke informiert oder die Richtung mit einem Pfeil auf einem Display anzeigt. Bei stehendem Fahrzeug könnte dann eine detaillierte Straßenkarte mit einem Punkt für die aktuelle Position angezeigt werden. Generell wird also über den Detaillierungsgrad und die Wahl des Mediums entschieden. Kontextbezogene Aktionen beschreiben den Fall, dass der Kontext eines Benutzers bestimmt, welche Aktionen auszuführen sind. So könnte ein Telefongespräch, für den Fall, dass der Benutzer sich in einer Besprechung befindet, an einen Anrufbeantworter geleitet werden. Hält der Benutzer sich hingegen in einem anderen Büro auf, so könnte das Gespräch an das entsprechende Telefon weitergeleitet werden.

Noch eine weitere Differenzierungsmöglichkeit liefern Barkhuus / Dey⁴⁹. Sie unterscheiden drei Level der Interaktivität. Dazu gehören Personalisierung, aktive- und passive Context-Awareness. Personalisierung bezeichnet die Möglichkeit eine Anwendung hinsichtlich des optischen Erscheinungsbildes oder ähnlicher Einstellungen (z.B. Klingelton des Mobiltelefons) den Vorlieben des Benutzers anzupassen. Dabei wird der Benutzer aber selbst aktiv und nimmt diese Einstellungen vor. Bezüglich der Context-Awareness der Anwendung unterscheiden Barkhuus / Dey nach dem Grad der Autonomie mit der die Kontextinformationen verarbeitet werden. Wenn ein Mobiletelefon zum Beispiel bei Eintritt in eine andere Zeitzone automatisch die Systemuhr umstellt, sprechen sie von aktiver Context- Awareness. Eine zurückhaltendere Variante wäre es, den Benutzer zu fragen, ob die Zeit umgestellt werden soll. In solch einem Fall ist von passiver Context- Awareness die Rede. Damit orientierten sie sich an Chen / Kotz die ebenfalls zwischen aktiver und passiver Context-Awareness unterschieden:

„Active context awareness: an application automatically adapts to discovered context, by changing the application’s behaviour.

Passive context awareness: an application presents the new or updated context to an interested user or makes the context persistent for the user to retrieve later.”⁵⁰

Barkhuus / Dey führten zu diesem Thema Untersuchungen durch, die zeigen sollten, welche Art der Interaktivität von Benutzern bevorzugt wird und warum das so ist. Sie kamen zu dem Ergebnis, dass Benutzer einen umso stärkeren Kontrollverlust wahrnehmen je autonomer die Anwendung handelt. Dennoch bevorzugten die meisten der Testpersonen passive und aktive Context-Awareness gegenüber der reinen Personalisierung⁵¹. Trotzdem sollten Anwendungen dieser Art mit Vorsicht entwickelt werden. Denn auch wenn Anwendungen mit aktiver Context- Awareness anfangs gut angenommen werden, kann das Gefühl des Kontrollverlusts dazu führen, dass sie nicht weiter verwendet werden. Barkhuus / Dey kommen also zu dem Schluss, dass der Nutzen einer Anwendung größer sein muss als der wahrnehmbare Nachteil durch die begrenzte Kontrolle, damit die Anwendung vom Benutzer akzeptiert wird⁵².

2.3.5. Kontextmodellierung

Um Kontextinformationen in einer Anwendung sinnvoll strukturieren zu können und somit die Verwendungsmöglichkeit dieser Informationen zu gewährleisten, ist es vorteilhaft, diese Informationen in einem Modell abzubilden. Um auf die Kontextmodellierung eingehen zu können, werden zunächst einmal die Begriffe Modell und Ontologie näher betrachtet.

Auch wenn vorhandene Definitionen des Begriffs Modell in verschiedene Richtungen gehen, gibt es zumindest zwei Punkte, in denen sie alle übereinstimmen⁵³:

1. Ein Modell ist eine Vereinfachung, eine Abstraktion der Realität.
2. Ein Modell ist die Übertragung von Wissen in ein Medium, das mechanische Simulation erlaubt.

Daraus hervor geht die Tatsache, dass zu einem Modell die Bestimmung der Elemente gehört, die in das Modell eingehen, sowie die Bestimmung der Zusammenhänge zwischen diesen Elementen. Zu den Elementen gehören dabei möglicherweise physikalische Größen, soziale Faktoren oder Objekte und deren Zustände. Die Beziehungen schließen physikalische Gesetze, soziale Bindungen und Abhängigkeiten oder Beziehungen, in denen Objekte zueinander stehen, ein.

Nach Stachowiak⁵⁴ gibt es drei Hauptmerkmale für ein Modell:

1. Abbildungsmerkmal - Jedes Modell ist ein Abbild oder Vorbild.
2. Verkürzungsmerkmal - Jedes Modell abstrahiert.
3. Pragmatisches Merkmal - Jedes Modell wird mit Hinblick auf einen bestimmten Verwendungszweck geschaffen.

Das Abbildungsmerkmal wird durch die Definition des Begriffs „Modell“ bestätigt. Das Verkürzungsmerkmal ergibt sich daraus, dass in den Modellierungsprozess nur das einfließt, was dem Modellschaffenden wichtig oder nützlich erscheint. Somit erfasst das Modell meist nicht alle Attribute und Individuen des Originals (Präterition). Allerdings kann das Modell auch Individuen und Attribute enthalten, die wiederum keine Entsprechung im Original haben (Abundanz). Werden Attribute des Originals im Modell mit anderen Bedeutungen belegt, spricht man von Transkodierung. Das Hervorheben bestimmter Attribute bezeichnet man als Kontrastierung. Der Grad der Abstrahierung ist für ein Modell nicht vorgeschrieben. Generell kann auch das Messen der Körpergröße eines Menschen schon als Modell angesehen werden.

Im Zuge des Semantic Web (s. Kap. 1.2) haben Ontologien im Bereich der Wissensrepräsentation einen Aufschwung erhalten. Ursprünglich stammt der Begriff Ontologie aus der Philosophie und beschreibt „die Lehre vom Sein, vom Wesen und den Eigenschaften des Seienden“⁵⁵. Sie entstand aus einem Teil von Aristoteles’ Metaphysik. Erst Anfang der 90er Jahre erhielt die Ontologie über den Forschungsbereich der Künstlichen Intelligenz Einzug in die Informatik. Heute versteht man darunter „ein formal definiertes System von Konzepten und Relationen“⁵⁶, und stellt die häufige Benutzung des Begriffes als Synonym für „Wissensmodell“ fest⁵⁷. Eine Ontologie umfasst Definitionen von Konzepten und Relationen sowie Inferenz- und Integritätsregeln. Der Unterschied einer Ontologie zu einer Taxonomie ist der, dass die Ontologie durch Relationen ein Netzwerk von Informationen aufbaut, während eine Taxonomie nur auf einer hierarchischen Ordnung beruht. Durch diese Sichtweise wird im Bereich der Künstlichen Intelligenz häufig von Semantischen Netzen gesprochen, wenn es um Ontologien geht. Der Inferenzmechanismus erlaubt es der Ontologie, sich weiteres Wissen anzueignen, ohne dabei auf den Input menschlicher Experten angewiesen zu sein, wie es normalerweise üblich ist. Man bezeichnet diesen Prozess als „Ontology learning“. Aus den in der Ontologie definierten Inferenzregeln können also Schlüsse gezogen werden, die zu weiteren Annahmen führen. Ein einfaches Beispiel beruht auf der Regel: „Alle Menschen sind sterblich“. Durch das vorhandene Wissen „Sokrates ist ein Mensch“ kann gefolgert werden: „Sokrates ist sterblich“. Dieses so genannte „Reasoning“ oder auch „Inferencing“ ist ein großer Vorteil, der für die Nutzung von Ontologien zur Modellierung spricht.

Um Modelle in der Informatik abbilden zu können, bedarf es einer geeigneten Darstellungsform des Modells. Dies ist meist eine Sprache, für die eine eindeutige Syntax sowie Semantik definiert ist. Die Anforderungen an die Darstellungsform für Modelle in der Informatik sind unter anderem:

- Austauschbarkeit der abgebildeten Informationen zwischen verschiedenen, vorher noch nicht bekannten Geräten
- Weiterverarbeitungsmöglichkeit auf verschiedenartigen Geräten

[...]

---

¹ Vgl. Weiser, Mark: Computer, 1991

² Mattern, Friedemann: Verschwinden, 2003, S. 4

³ o.V.: RFID, 2004

⁴ http://www.writely.com/; http://spreadsheets.google.com/

⁵ http://www.w3c.org/

⁶ http://swoogle.umbc.edu/

⁷ Vgl. Andrews, Tony et al.: Services, 2003, S. 8

⁸ Vgl. Garlan, David: Aura, 2002, S. 1

⁹ Vgl. Strang, Thomas: Ubiquitous, 2005, S. 3

¹⁰ Vgl. Weiser, Mark: Computer, 1991

¹¹ Fleisch, Elgar: Dinge, 2005

¹² Vgl. Mattern, Friedemann: Verschwinden, 2003, S. 4

¹³ Vgl. Weiser, Mark: Computer, 1991

¹⁴ Weiser, Mark: Computer, 1991

¹⁵ Vgl. Diekmann, Thomas / Hagenhoff, Svenja: Ubiquitous, 2003, S. 10f.

¹⁶ Vgl. Diekmann, Thomas / Hagenhoff, Svenja: Ubiquitous, 2003, S. 14

¹⁷ Diekmann, Thomas / Hagenhoff, Svenja: Ubiquitous, 2003, S. 24

¹⁸ http://www.zeit.de/2006/11/RFID-Umfrage

¹⁹ Vgl. Samulowitz, Michael: Dienstnutzung, 2002, S. 39f.

²⁰ Samulowitz, Michael: Dienstnutzung, 2002, S. 39

²¹ Vgl. McGrath, Robert E.: Discovery, 2000, S. 1

²² http://www.brockhaus.de/

²³ http://www.m-w.com/

²⁴ Vgl. Schilit, Bill N. / Theimer, Marvin M.: Mobile, 1994, S. 2

²⁵ Vgl. Strang, Thomas / Linnhoff-Popien, Claudia: Modeling, 2004, S. 2

²⁶ Vgl. Dey, Anind K.: Understanding, 2001, S. 3

²⁷ Vgl. Schilit, Bill N. / Adams, Norman / Want, Roy: Context-Aware, 1994, S. 1

²⁸ Vgl. Chen, Guanling / Kotz, David: Context-Aware, 2000, S. 2

²⁹ Schilit, Bill N. / Adams, Norman / Want , Roy: Context-Aware, 1994, S. 1

³⁰ Lieberman, Henry / Selker, Ted: Context, 2000, S. 618

³¹ Dey, Anind K. / Abowd, Gregory D.: Context, 1999, S. 3f.

³² Schilit, Bill N. / Adams, Norman / Want, Roy: Context-Aware, 1994, S. 1

³³ Dey, Anind K. / Abowd, Gregory D.: Context, 1999, S. 5

³⁴ Ryan, Nick / Pascoe, Jason / Morse, David: Enhanced, 1998, S. 1

³⁵ Brown, Martin G.: Mobility, 1996, S. 4

³⁶ Cooperstock, Jeremy R. et al.: Reactive, 1995

³⁷ Elrod, Scott et al.: Responsive, 1993, S. 84

³⁸ Hull, Richard / Neaves, Philip / Bedford-Roberts, James: Situated, 1997

³⁹ Rekimoto, Jun / Ayatsuka, Yuji / Hayashi, Kazuteru: Situated, 1998, S. 1

⁴⁰ Fickas, Stephen / Kortuem, Gerd / Segall, Zary: Wearable, 1997, S. 2

⁴¹ Rothermel, Kurt / Bauer, Martin / Becker, Christian: Weltmodelle, 2003, S. 124

⁴² Dey, Anind K. / Abowd, Gregory D.: Context, 1999, S. 6

⁴³ Vgl. Schilit, Bill N. / Adams, Norman / Want, Roy: Context-Aware, 1994, S. 1

⁴⁴ Vgl. Weiser, Mark, 1993: Ubiquitous, S. 1

⁴⁵ http://de.wikipedia.org/wiki/Wearable_Computing

⁴⁶ Schilit, Bill N. / Adams, Norman / Want, Roy, Context-Aware, 1994, S. 2ff.

⁴⁷ Schilit, Bill N. / Adams, Norman / Want, Roy, Context-Aware, 1994, S. 5

⁴⁸ Rothermel, Kurt / Bauer, Martin / Becker, Christian: Weltmodelle, 2003, S. 126f.

⁴⁹ Vgl. Barkhuus, Louise / Dey, Anind: Control, 2003, S. 150

⁵⁰ Vgl. Chen, Guanling / Kotz, David: Context-Aware, 2000, S. 3

⁵¹ Vgl. Barkhuus, Louise / Dey, Anind: Control, 2003, S. 154

⁵² Vgl. Barkhuus, Louise / Dey, Anind: Control, 2003, S. 155

⁵³ Vgl. Steimann, F. / Nejdl, W.: Modellierung, 2000, S. 1

⁵⁴ Stachowiak, Herbert: Modelltheorie, 1973

⁵⁵ http://www.langenscheidt.de/fremdwb/indexextra.html?qstr=ontologie

⁵⁶ http://de.wikipedia.org/wiki/Ontologie_(Informatik)

⁵⁷ http://www.semantic-web.at/10.36.29.catchword.kontext.ontologie.htm