dagegen müssen nicht an einzelne Nutzer angepasst werden. Die dort genutzten Entscheidungsmodelle müssen an die dynamische Menge von Sensortypen beziehungsweise Kontextinformationen angepasst werden können. Danach können sie aber auf alle Nutzer gleichermaßen angewendet werden. Das bedeutet, dass für die weiß dargestellten Kontextdimensionen in der Regel ein nutzerübergreifendes Entscheidungsmodell ausreichend ist.
• Der Nutzer sollte Einblick in die Informationen haben, welche von seinem System erfasst werden.
• Der Benutzer selbst sollte die Möglichkeit haben, zu bestimmen, welche Informationen er bereit stellt.
• Nachträgliche Installation/Konfiguration von Sensoren sollte ohne Eingreifen seitens des Nutzers möglich sein (eventuell begleitet von einer Notifikation des Nutzers, um den vorangegangenen Aspekt zu berücksich-tigen).
3.2.2 Informationsgewinnung
Der Bereich der Informationsgewinnung hat eine hohe Korrelation mit dem Aufgabenbereich der Informations-quellen. Durch die lose Kopplung zwischen den Informationsquellen und der Informationsgewinnung entstehen weitere Aufgabenbereiche. Als Grundlage zur Informationsgewinnung müssen Informationsquellen aufgefunden und verwaltet werden. Diese Aufgabe wird vomSensorverzeichnisübernommen.
Um keine unnötige Redundanz bei der Verwaltung der Informationsquellen zu erhalten, soll möglichst nur ein System zur Informationsgewinnung für verschiedene Kontextdimensionen eingesetzt werden. Daher müssen Infor-mationsquellen verschiedenster Art angebunden werden können. Für eine spätere Suche muss die Relation einer Informationsquelle zu der jeweiligen Kontextdimension bestimmt werden können. Hierbei spielt dieBeschreibung einer Informationsquelle eine zentrale Rolle (siehe Abschnitt 3.3).
Sensorverzeichnis
Das Sensorverzeichnis bildet die Schnittstelle zwischen den Sensoren und den Diensten, welche auf die Sensorda-ten zugreifen möchSensorda-ten. Das Sensorverzeichnis registriert die Sensoren innerhalb seiner Umgebung (beispielsweise dem lokalen Netzwerk). Hierzu greift es auf Methoden zur Lokalisation von Diensten zurück (siehe 3.3).
Zu seinen zentralen Funktionalitäten gehört:
• Schnittstelle zur Registrierung von Sensoren.
• Suche nach verfügbaren Sensoren in der Umgebung.
• Bereitstellung von Referenzen auf die Schnittstellen der Sensoren.
• Erfassen/Anbieten der Beschreibungen der Sensoren.
• Überwachung der Verfügbarkeit der Sensoren.
Das Sensorverzeichnis bietet anderen Diensten die Möglichkeit, Informationsquellen schnell und ohne zusätzli-chen Aufwand aufzufinden. Ein direkter Zugriff auf die Sensoren (ohne Sensorverzeichnis) ist prinzipiell möglich, setzt jedoch voraus, dass der entsprechende Sensor und dessen Schnittstellen vorab bekannt sind. Ein zentrales Management der Sensoren erspart einen zusätzlichen Funktionsumfang auf der Seite des Sensors. Somit muss ein Sensor nur über Funktionen zur Bereitstellung seiner Informationen verfügen.
Dies schließt jedoch nicht aus, dass ein Sensor durchaus auch in den Listen unterschiedlicher Sensorverzeich-nisse geführt werden kann. Zur Skalierbarkeit in größeren Szenarien könnten auch mehrere SensorverzeichSensorverzeich-nisse gekoppelt werden. Sofern jedes Sensorverzeichnis für einen speziellen Bereich (beispielsweise ein Gebäude) zu-ständig ist, könnten Suchanfragen an das entsprechende Sensorverzeichnis weitergeleitet werden, sobald dieser Bereich für die Anfrage relevant wird.
Suchdienst
Der Suchdienst ermöglicht es anderen Diensten, Suchanfragen an Sensoren zu stellen. Er kann dabei auf die Liste der verfügbaren Sensoren des Sensorverzeichnisses zurückgreifen. Je nach Bedarf können unterschiedliche Suchdienste mit verschiedenen Suchalgorithmen und Eigenschaften zum Einsatz kommen:
• Semantische Suche:Für das gegebene Szenario muss ein anfragender Dienst die Möglichkeit haben, diejeni-gen Sensoren anzufradiejeni-gen, welche zu einer bestimmten Kontextdimension und zu einem oder mehreren Kon-textobjekten in Relation stehen, beziehungsweise relevante Informationen anbieten. Hierzu ist es notwendig, unter Nutzung der Schnittstellenbeschreibung und deren semantischer Beschreibungsmerkmale sowie einer Ontologie relevante Sensoren zu identifizieren.
• Iterative Suche:Zu Beginn einer Suchanfrage werden nur wenige Informationen verfügbar sein. In der Re-gel wird eine Suche mit den Angaben über die Kontextdimension und über das Kontextobjekt gestartet. Je nach verfügbaren Sensoren werden jedoch meist nur wenige Informationen direkt mit dem Kontextobjekt in Verbindung stehen. Weitaus mehr Informationen lassen sich ermittelt, wenn diese Informationen wieder-um genutzt werden können, wieder-um weitere relevante Informationsquellen zu identifizieren und anzufragen.
3 Konzept und Architektur 31
Beispielsweise kann so in einem ersten Schritt festgestellt werden, in welchem Raum sich ein betrachtetes Objekt befindet, um dann in einem nächsten Schritt auch die Informationsquellen in dem Raum zur Be-schreibung der Situation des Objekts heranzuziehen. Hier gilt es eine iterative Suche umzusetzen, welche die Menge der Suchergebnisse schrittweise durch weitere Suchanfragen über neu erhaltene Informationen erweitern kann.
Qualität der Suche und der Suchergebnisse
Die Umsetzung der Suche hat einen wesentlichen Einfluss auf die Erfüllung der Qualitätsanforderungen (siehe Abschnitt 3.4) durch das Gesamtsystem. Es müssen in kurzer Zeit viele aussagekräftige Informationen gesammelt werden, um schließlich gute Entscheidungen treffen zu können. Ein weiterer wichtiger Faktor in diesem Zusam-menhang ist die Integration von Puffermechanismen zur Beschleunigung oder zur Einsparung von Suchanfragen.
3.2.3 Informationsauswertung
Wie in der Abbildung 3.3 dargestellt wurde, stellt die Informationsauswertung die Schnittstelle zwischen den Diens-ten, welchen einen Kontext nutzen wollen und den Diensten zur Erfassung der Informationen, dar. Die Informa-tionsauswertung wird für eine bestimmte Kontextdimension instanziiert. Für die Nutzung des Kontextes bietet die Informationsauswertung eine Schnittstelle, welche der eines Sensors entspricht. Auf diese Weise können die Resultate einer Kontextdimension auch im Rahmen weiterer Kontextdimensionen herangezogen werden.
Wie in Abschnitt 2.4.3 beschrieben kann man zwischen verschiedenen Kontextdimensionen unterscheiden. Bei-spiele für Kontextdimensionen sind Verfügbarkeit, Beziehung, Tätigkeit, Standort oder verfügbare Endgeräte.
Für jede Kontextdimension sind unterschiedliche Mengen von Sensoren relevant, entsprechend werden andere Suchanfragen gestellt. Ebenso unterscheidet sich die Art der Auswertung je nach betrachteter Kontextdimension.
Während sich die verfügbare Endgeräte über relativ statische Methoden bestimmen lassen, wird für die Bestimmung der Verfügbarkeit ein sehr komplexes und adaptives Verfahren benötigt.
Je nach Kontextdimension unterscheiden sich auch der Mechanismus zum Starten der Auswertung und die Vorhaltung der Kontexte. Ein Beziehungskontext zwischen zwei Personen kann erst zu dem Zeitpunkt der Anfrage gestellt werden, indem beide Personen miteinander in Kontakt treten oder es müsste jede mögliche Kombination vorab bestimmt werden. Dieser Beziehungskontext hat jedoch in der Regel eine relativ lange Gültigkeitsdauer und braucht in diesem Zeitraum nicht neu ermittelt zu werden. Auf der anderen Seite kann die Verfügbarkeit einer Person jederzeit ermittelt werden. Eine periodische Bestimmung der Verfügbarkeit bringt zudem den Vorteil, zum Zeitpunkt eines eingehenden Anrufes sofort auf den aktuell gültigen Wert zurückgreifen zu können, ohne eine zusätzliche Verzögerung in Kauf nehmen zu müssen, welche eine Suche mit sich bringen würde. Die Verfügbarkeit hat jedoch in der Regel nur eine relativ kurze Gültigkeit und muss daher in relativ kurzen Abständen neu ermittelt werden.
Auswertung
Die Auswertung analysiert den Kontext eines Kontextobjektes für eine bestimmte Kontextdimension. Das Resultat ist die in diesem Zusammenhang ermittelte Kontextklasse. Je nach Kontextdimension werden hierzu unterschiedli-che Verfahren angewandt. Es gibt in dem Bereich drei grundlegende Ansätze:
• Statische Auswertung:Eine statische Auswertung läuft nach Regeln ab, die sich zur Laufzeit nicht ändern.
Hierzu zählen auch skriptbasierte Ansätze.
• Adaptive, unüberwachte Auswertung:Eine adaptive Auswertung kann das Modell, welches zur Auswer-tung genutzt wird zur Laufzeit ändern beziehungsweise anpassen. Hierzu erhält das Verfahren jedoch nur die Informationen, welche in der Anfrage selbst enthalten sind.
• Adaptive, überwachte Auswertung:Eine überwachte Auswertung, erhält (im Gegensatz zur unüberwach-ten) neben den Anfragen selbst auch nochFeedback(siehe Abschnitt 3.2.4).
Insbesondere bei Kontextdimensionen, in welchen dasrichtigeResultat stark von den Wünschen und vom Emp-finden eines Nutzers abhängig ist, wird eine adaptive, überwachte Auswertung benötigt. Dies gilt im Besonderen für die Dimensionen der Verfügbarkeit, welche eine zentrale Rolle im Zusammenhang mit einem System für Kom-munikationsmanagement einnimmt.
32 3.2 Gesamtarchitektur und Aufgabenbereiche
Feedbackschnittstelle
Eine weitere Funktion der Informationsauswertung ist es, eine Schnittstelle für Feedback zu bieten. Feedback kann bei Kontextdimensionen, welche ein adaptives und überwachtes Verfahren zur Auswertung benötigen, be-nutzt werden, um den Prozess zur Adaption mit neuen Angaben zu versorgen. Hierzu kann ein Nutzer über unter-schiedliche Wege Feedback geben (wie in Abschnitt 3.2.4 näher erläutert wird). Die Informationsauswertung bietet hierfür den Anknüpfungspunkt und bestimmt (je nach Instanziierung), wie das Feedback verarbeitet wird.
3.2.4 Kontextnutzung, Benutzer und Feedback
Die Anwendung, welche schließlich auf den Kontext zurück greift, wird als kontextberücksichtigende Anwendung (engl. Context-aware Application) bezeichnet. Bei den Szenarien aus Abschnitt 2.2, greift die Telefoniesoftware auf den Kontext zurück und nimmt somit die Rolle der kontextberücksichtigenden Anwendung ein. Es existieren eine Reihe weiterer Anwendungsmöglichkeiten, welche in Abschnitt 7 aufgeführt werden.
Feedback wird im Zusammenhang mit einer adaptiven, überwachten Auswertungsmethode relevant. Mit Feed-back wird die Antwort beziehungsweise die Reaktion des Benutzers auf das Resultat der Kontextbestimmung be-zeichnet. Das Feedback enthält neben der Anfrage, auf die sich das Feedback bezieht, auch das in diesem Zusam-menhang erwünschte Resultat. Somit kann das Feedback auch als ein Ausschnitt der Vorstellungen eines Benutzers betrachtet werden. Die Problematik in diesem Bereich entsteht im Zusammenhang mit der vierten Anforderung aus Abschnitt 2.3: der Minimierung des Konfigurationsaufwandes seitens des Benutzers. Feedback vom Benutzer zu benötigen, bedeutet mehr Aufwand zu erzeugen. Da das System jedoch auf Feedback angewiesen ist, sollte dieser Aufwand so gering wie möglich gehalten werden. Daher ist es ein weiteres Ziel an dieser Stelle möglichst einfach zu nutzende Schnittstellen für den Benutzer anzubieten. Je nach Zusammenhang zwischen dem Feedback und dem Nutzerkonzept, welches vom bestehenden Modell beschrieben wird, kann zwischen mehreren Arten von Feedback unterschieden werden:
• Negatives Feedback: Wenn die Entscheidung des Systems nicht dem Konzept des Benutzers entspricht, kann man mittels Feedback korrigierend auf das Modell einwirken. Dieses Feedback widerspricht somit dem Nutzerkonzept, welches von dem aktuell bestehenden Modell beschrieben wird und wird somit alsnegatives Feedbackbezeichnet.
• Positives Feedback:Entspricht das Feedback dem Nutzerkonzept, welches das bestehende Modell beschreibt, wird dies in dieser Arbeit alspositives Feedbackbezeichnet. Positives Feedback ist nicht zwangsläufig notwen-dig, um ein Modell anzupassen, es kann jedoch genutzt werden, um das Modell zu festigen.
• Falsches Feedback: Feedback, welches nicht dem eigentlichen Konzept des Benutzers entspricht, wird als falsches Feedbackbezeichnet. Falsches Feedback kann beispielsweise durch ein Versehen seitens des Benutzers entstehen, oder ebenso wenn ein automatisierter Prozess zur Erzeugung von Feedback genutzt wird. Falsches Feedback führt möglicherweise zu einem Fehlverhalten des Modells und sollte daher weitgehend vermieden werden.
Je nach Kontextdimension und Anwendung entstehen unterschiedliche Möglichkeiten, Feedback vom Benutzer zu beziehen. In einigen Bereichen ist es von Vorteil, eine solcheFeedback-Schnittstelledirekt in die Anwendung zu integrieren oder als zusätzliche Komponente auf das Endgerät zu installieren. Eine solche Komponente wird im Rahmen dieser Arbeit auch alsFeedbackagentbezeichnet.
Ein wesentliches Unterscheidungsmerkmal zwischen den Ansätzen für einen Feedbackagent ist die Art und der Zeitpunkt der Generierung des Feedbacks (siehe auch Abschnitt 3.2.4). Wird das Feedback aus einer bestimmten Si-tuation heraus gegeben (Implizites Feedback), können direkt die Merkmale, die diese SiSi-tuation beschreiben genutzt werden. Wird das Feedback erst im Nachhinein gegeben, so bezieht sich das Feedback auf Merkmale einer zeitlich zurückliegenden Situation (Explizites Feedback). Für das explizite Feedback müssen die Merkmale zurückliegender Entscheidungen in einer Historie gehalten und für den Benutzer zur Entscheidungsfindung einsehbar sein. Diese Variante erfordert jedoch deutlich mehr Aufwand und eine Oberfläche, über die es dem Benutzer möglichst einfach gemacht wird, die Merkmale der jeweiligen Situation zu betrachten und selbst eine Entscheidung zu treffen.