Prozess der Kontextverarbeitung

3.2. Prozess der Kontextverarbeitung 61

der Verantwortlichkeit, der Frequenz, der Quelle oder nach dem Akquisition-prozess (acquisition process) unterschieden werden. Diese unterscheiden sich nach [PZCG14] wie folgt:

Basierend auf der Verantwortlichkeit Kontext kann entweder aktiv angefragt werden (pull) oder bei einer Veränderung des entsprechenden Kontextat-tributs (publish and subscribe / push). Die zweite Variante erfordert es, dass ein Empfänger sich als Interessent für Veränderungen des chenden Kontextattributs registriert, um bei einer Veränderung entspre-chend benachrichtigt zu werden.

Basierend auf der Frequenz Hierbei kann zwischen einer zeitpunktbezoge-nen und einer intervallbasierten Kontextakquisition unterschieden wer-den. Zeitpunktbezogen, im exakten Moment des Ereignisses, beispiels-weise in dem Moment, in dem ein Beschleunigungssensor eine Beschleu-nigung registriert. Oder intervallbasiert (periodically), wenn die Sens-ordaten periodisch abgefragt (pull) oder aktualisiert (push) werden. Ein Beispiel ist die regelmäßige Überprüfung verfügbarer Netzwerke zur Mo-bilkommunikation durch ein mobiles Gerät.

Basierend auf der Quelle Die Bereitstellung von Kontextdaten kann direkt durch den Zugriff auf die entsprechende Programmierschnittstelle (API) der Sensorhardware erfolgen. Die Bereitstellung kann jedoch ebenfalls durch eine entsprechende Systemunterstützung in Form einer Middlewa-re erfolgen, die im Gegensatz zum diMiddlewa-rekten Sensorzugriff eine Abstrakti-on vAbstrakti-on Low-level-Schnittstellen bietet und hierdurch die Wiederverwend-barkeit erhöht. Die dritte Variante stellt ein sogenannter Kontext-Server dar, wie er ebenso in der Klassifikation der verschiedenen Architektu-ren des Sensorzugriffs von Baldauf et al. in [BDR07] vorgeschlagen wird.

Dieser kann ressourcenbeschränkte Geräte unterstützen, die benötigten Kontextinformationen zu beziehen, wenn diese sie nicht selbst akquirie-ren können.

Basierend auf dem Sensortyp Wie in Abschnitt 3.1.3 beschrieben wurde, kön-nen die Sensortypen zur Akquisition von Kontextdaten in physische, vir-tuelle und logische Sensoren unterschieden werden.

Basierend auf dem Akquisitionsprozess In diesem Fall wird unterschieden, ob eine Kontextinformation direkt durch einen Sensor bereitgestellt wird oder ob die Kontextinformation mithilfe weiterer Verarbeitungsschritte aus existierenden Kontextdaten ermittelt wird.

In Bezug auf diese Arbeit ist dabei insbesondere die Akquisition basierend auf der Quelle relevant, da die hohe Heterogenität mobiler Geräte es erfor-dert, unterschiedlichste Sensoren mithilfe wiederverwendbarer Schnittstellen zu erfassen.

Je nach Prozessdefinition wird der Akquisition von Kontextdaten ebenfalls die Speicherung derselbigen zugerechnet. In [RCKZ13] wird die Speicherung

hingegen als zusätzlicher Schritt im Zusammenhang mit der Verarbeitung von Kontextdaten auf mobilen Geräten gesehen. Die Speicherung größerer Daten-mengen auf ressourcenbeschränkten Geräten, die zusätzlich nur sporadisch mit der Infrastruktur verbunden sind, stellt erhöhte Anforderungen an diesen Prozessschritt, ist allerdings von enormer Bedeutung für die Ermittlung grö-ßerer Zusammenhänge in Kontextdaten, da dies häufig nur in Verbindung mit der Analyse oder Berücksichtigung vergangener Kontextinformationen mög-lich ist.

3.2.2. Modellierung und Repräsentationsformen

Im Anschluss an die Akquisition von Kontextinformationen können diese durch unterschiedliche Repräsentationen in Form verschiedener Kontextmo-delle dargestellt werden. Unter der Modellierung ist hierbei die Nutzung gene-rischer Datenmodelle zu verstehen, um zu beschreiben, wie Kontextinformatio-nen repräsentiert und benutzbar gemacht werden [XP12]. EinKontextmodell definiert und speichert in diesem Zusammenhang die Werte von Kontextat-tributen in einer maschinenlesbaren Form und beschreibt ihre Beziehungen zueinander. Es ist nach von van Sinderen et al. definiert als:

„A context model is an information model designed to represent context information. It describes context attributes, their mutual relationships, and their values.“ [vSvHW⁺06]

Neben dieser auf die systemtechnische Modellierung bezogene Definition existiert eine frühere Definition von Henricksen, die ein Kontextmodell basie-rend auf den Kontextinformationen, die es enthält, klassifiziert:

„A context model identifies a concrete subset of the context that is reali-stically attainable from sensors, applications and users and able to be exploited in the execution of the task. The context model that is employ-ed by a given context-aware application is usually explicitly specifiemploy-ed by the application developer, but may evolve over time.“ [Hen03]

Hiernach identifiziert ein Kontextmodell eine Teilmenge von Kontextinfor-mationen, die von Sensoren, Anwendungen und Nutzern wahrgenommen wer-den kann und der üblicherweise durch wer-den Anwendungsentwickler einer kon-textsensitiven Anwendung definiert ist. In diesem Zusammenhang können nach [BBH⁺10] Kontextmodelle in statische oder dynamische Modelle unter-schieden werden, wobei statische Modelle darauf beschränkt sind, vorher de-finierte Strukturen von Kontextmodellen zu halten, wohingegen dynamische Modelle bei der Verwendung erweitert oder angepasst werden können.

Der Prozess, der Kontextdaten in eine Modellierung bringt, gliedert sich nach [PZCG14] dabei in zwei Schritte. In eine Modellierungsphase, in der neue Kontextinformationen in Form von Kontextattributen in Beziehung zueinan-der gesetzt und mit Qualitätsattributen versehen werden, und in eine zweite Phase, in der sowohl existierende als auch neue Kontextinformationen in Form des Modells zur Verwendung bekannt gemacht werden.

3.2. Prozess der Kontextverarbeitung 63

Im Laufe der Jahre haben sich hierfür gewisse Gruppen von Repräsentati-onsformen zur Kontextmodellierung etabliert, die im Folgenden angelehnt an [SLP04] und [XP12] vorgestellt werden:

Key-Value-Modelle (key value models) Dieser Ansatz verwendet einfache Schlüssel-Wert-Kombinationen, um Kontextdaten zu modellieren. Der Vorteil dieser Modellierung liegt in der Einfachheit der Implementie-rung in relationalen Datenbanksystemen. Jedoch erlaubt es dieser An-satz nicht, komplexe semantische Strukturen und Zusammenhänge aus-zudrücken und direkt Schlussfolgerungen aus diesen Strukturen zu zie-hen.

Auszeichnungsschemata (markup scheme) Bei diesem Ansatz werden mit-tels semistrukturierter Beschreibungssprachen wie der Extensible Mar-kup Language (XML) Kontextattribute und ihre Werte anhand einer hier-archischen Struktur aus Markup Tags beschrieben. Diese Form der Kon-textmodellierung wird vor allem dort angewendet, wo versucht wird, die hohe Dynamik und Komplexität von Kontextinformationen adäquat zu beschreiben, da sie zur Laufzeit erweiterbar ist.

Grafische Modelle (graphical models) Grafische Modelle bestehen aus einer Menge von grafischen Elementen, die genutzt werden, um Kontextinfor-mationen zu repräsentieren. Ein in diesem Zusammenhang weitverbrei-teter Ansatz ist die Verwendung der Unified Modeling Language (UML).

Ein Beispiel hierfür findet sich in der von Henricksen vorgeschlagenen Erweiterung des Object-Role Modeling in [HIR03].

Objektorientierte Modelle (object oriented models) Objektorientierte Modelle versuchen die etablierten und erfolgreichen Konzepte der Ob-jektorientierung, unter anderem Kapselung und Wiederverwendbarkeit, auf das Problemfeld der Kontextmodellierung zu übertragen, um die Dy-namik des Kontexts innerhalb von ubiquitären Systemen beherrschbar zu machen. Das objektorientierte Paradigma zur Verarbeitung von Kon-textdaten ist dabei insbesondere für den Entwickler objektorientierter Anwendungen als leicht erlernbar und verständlich anzusehen.

Logikbasierte Modelle (Logic based Models) Bei dieser Modellierungsform wird Kontext als Menge von Elementen innerhalb eines logikbasier-ten Systems repräsentiert, welches Ausdrücke, Faklogikbasier-ten und Regeln de-finiert. Die Aktualisierung der Kontextinformation findet hier üblicher-weise durch eine Anpassung der Faktenbasis statt. In diesem logikba-sierten System können dann durch Schließen (reasoning) aus der Wis-sensbasis direkt ermittelte oder abgeleitete höherwertige (High-level)-Kontextinformationen bereitgestellt werden.

Ontologiebasierte Modelle (ontology based) Ontologien versuchen als strukturierendes Mittel die formal geordnete Darstellung und den Sinn-zusammenhang zwischen einer Menge von Begrifflichkeiten innerhalb

eines bestimmten Bereichs zusammenzufassen. Sie werden als eine viel-versprechende Art der Kontextrepräsentation angesehen, wenn es um die Abbildung vielfältiger Zusammenhänge innerhalb maschinenlesbarer Datenstrukturen geht.

Für eine weitergehende Bewertung der unterschiedlichen Modellierungsan-sätze wird auf [PZCG14] verwiesen. Zusammenfassend soll an dieser Stelle jedoch festgehalten werden, dass die Auswahl eines geeigneten Modellierungs-ansatzes stark von der konkreten Problemstellung abhängig ist und im We-sentlichen durch den nun vorgestellten nächsten Prozessschritt, dem Reaso-ning, geprägt ist.

3.2.3. Reasoning

Unter dem Begriff des Reasonings wird die Ableitung und Generierung neuen Wissens verstanden [VIP16]. In Bezug auf die Verarbeitung von Kontextda-ten erfolgt in diesem Prozessschritt die Analyse der KontextdaKontextda-ten, um hieraus neue Informationen und letztlich neues Wissen über die Zusammenhänge in den Daten herzustellen.

Der Prozessschritt des Reasonings weist entsprechend eine hohe Ähnlich-keit zu etablierten Prozessen für Mustererkennung und Wissensgenerierung wieCRISP-DM[She00] oderKDD[FPSS96] auf; es existieren jedoch auch do-mänenspezifische Unterschiede.

Die allgemeine Erfordernis des Reasonings entsteht aus zwei Eigenschaften von Low-level-Kontextdaten: Ihrer Ungenauigkeit, die sich beispielsweise in einer Doppeldeutigkeit (ambiguity) zeigt, und ihrer Unsicherheit (uncertaincy) [PZCG14]. Der Prozess des Reasonings versucht diese Probleme aufzulösen und entsprechende Muster zu erkennen. Er besteht aus drei Schritten, der Vorverarbeitung von Kontextdaten, der Sensordatenfusion und der Kontext-Inferenz, die im Folgenden jeweils kurz beschrieben werden:

Vorverarbeitung von Kontextdaten Die Vorverarbeitung stellt einen wesent-lichen Schritt dar, wenn aus bestehenden Daten auf neues Wissen geschlossen werden soll. Die Vorverarbeitung von insbesondere Sensordaten bedarf dabei zunächst einer Korrektur fehlender Werte (imputation of missing values), der Entfernung unüblicher und unrichtiger Werte (outlier detection) und gegebe-nenfalls auch einer Konsistenzprüfung. Dieser Verarbeitungsschritt entspricht im KDD-Prozess dem Teilschritt der Vorverarbeitung.

Sensordatenfusion Ein weiterer, speziell für die Verarbeitung von Kontext-daten relevanter Schritt ist die Zusammenführung einzelner SensorKontext-daten hin zu einer genaueren und vollständigeren Sicht; ein Schritt, der insbesondere bei Sensordaten als relevant angesehen wird, um die Genauigkeit gegenüber einem einzelnen Sensor zu erhöhen [HL97]. Dieser Verarbeitungsschritt ent-spricht im KDD-Prozess weitestgehend dem Teilschritt der Transformation.

3.2. Prozess der Kontextverarbeitung 65

Kontext-Inferenz In diesem Schritt werden aus Low-level-Informationen neue High-level-Kontextinformationen erzeugt. Ein Beispiel hierfür findet sich nach [PZCG14] in der Verarbeitung von GPS-Informationen in Bezug auf den Höhen- und Breitengrad hin zu der Information, dass es sich um ein Café han-delt. Ein weiterer Schritt kann nun die Auswertung einer Historie beinhalten, anhand derer festgestellt wird, dass es sich um einen vielbesuchten Ort die-ses Nutzers handelt. Als ein Teil der Kontext-Inferenz²findet innerhalb dieses Verarbeitungsschritts aus Sicht des KDD-Prozesses das Data Minings (die Mu-stererkennung) statt.

Diese Mustererkennung kann mithilfe unterschiedlicher Verfahren erfolgen.

Bei der Mustererkennung in Kontextdaten mobiler Geräte wurden von Perera et al. in [PZCG14] sechs verschiedene Kategorien identifiziert, die sich hierfür besonders gut eignen und entsprechend oft in existierenden Lösungsansätzen angewendet wurden:

Überwachtes Lernen (supervised learning) Beim überwachten Lernen han-delt es sich um einen weitverbreiteten Ansatz im Bereich des statisti-schen Schließens. Hierbei versucht ein Lernalgorithmus eine Abbildung zu finden, die möglichst gut jedem Eingabewert den vermuteten Ausgabe-wert zuordnet. Nach diesem Lernprozess, auch als Training bezeichnet, sollte das so entstandene Modell fähig sein, für neue und unbekannte Beispiele, die Testmenge, eine korrekte Ausgabe zu liefern. Die Abwei-chung zum tatsächlichen Ausgabewert wird im Fall einer falschen Aus-gabe mithilfe eines Fehlermaßes erfasst. Das Ziel ist es entsprechend, das Fehlermaß auf der Testmenge, mit der nicht trainiert wird, zu minimie-ren. Für die Aufteilung von Trainings- und Testmenge kommen häufig Kreuzvalidierungsverfahren zur Anwendung. Erfolgt das Lernen aller-dings mit dem Ziel zukünftige Ereignisse zu erkennen, gilt es dies bei der Aufteilung dahingehend zu berücksichtigen, dass beim Lernen kei-ne Information über diese zukünftigen Ereignisse verwendet wird. Ent-sprechend kann hierzu die in Abbildung 3.3 gezeigte Aufteilung genutzt werden.

Trainingsmenge Testmenge Zeit

Abbildung 3.3.:Exemplarische Selektion von Trainings- und Testmenge

Unüberwachtes Lernen (unsupervised learning) Unüberwachtes Lernen un-terscheidet sich vom überwachten Lernen dadurch, dass die Ausgabewer-te nicht im Voraus bekannt sind. Das Lernverfahren versucht hier in den

2Obwohl der mit dem Begriff der Inferenz verbundene Prozess einer Schlussfolgerung deutlich weiter gefasst ist, bezieht sich dieser im Umfeld der Verarbeitung von Kontextdaten vornehm-lich auf die Mustererkennung (vergleiche [PZCG14]) und wird im Folgenden entsprechend ver-wendet.

Eingabewerten Muster zu erkennen und hieraus beispielsweise Klassen-zugehörigkeiten abzuleiten. Das so entstandene Modell kann die erlern-ten Muster dann auf neue, zuvor unbekannte Eingabewerte anwenden.

Regelsysteme Regelsysteme bilden die einfachste Art des Schließens ab, in-dem sie sich auf If-then-else-Konstrukte beschränken. Nach [LD10] stel-len sie zudem die populärste Gruppe von Verfahren dar. Regelbasierte Systeme werden dabei oft im Zusammenhang mit ontologischem Schlie-ßen verwendet.

Fuzzylogik Fuzzylogik oder unscharfe Logik erlaubt näherungsweise Aussa-gen und dient der Modellierung von Unsicherheit, um Zustände um-gangssprachlich zu beschreiben, und ähnelt dem probabilistischen Schlie-ßen. Die Konfidenz drückt in diesem Fall den Grad der Zugehörigkeit zu einer Gruppe aus. Fuzzylogik wird seit längerer Zeit in Kombination mit anderen Verfahren verwendet, um Unsicherheit zu modellieren und so am Beispiel der Temperatur die Zustände „kalt“, „relativ warm“ und

„sehr warm“ anstatt einer konkreten Temperaturangabe in Grad Celsius abzubilden.

Ontologisches Schließen Ontologiebasierte Systeme basieren auf der Be-schreibung von Zusammenhängen in einer Wissensbasis, wie sie im Zu-sammenhang mit der ontologiebasierten Modellierung erwähnt wurden.

Ontologisches Schließen bietet sich entsprechend vor allem in Zusam-menhang mit ontologischer Modellierung von Kontextinformationen an.

Probabilistisches Reasoning Bei diesen Verfahren werden Schlüsse und Ent-scheidungen auf Basis von Wahrscheinlichkeiten getroffen, die den ein-zelnen Fakten zugehörig sind. Ein prominentes Beispiel sind versteckte Markov-Ketten, bei denen das Ereignis, auf das es zu schließen gilt, un-bekannt ist und nur mithilfe von Beobachtungen und anhand von Wahr-scheinlichkeiten Schlüsse abgeleitet werden. Sie kommen insbesondere bei der Aktivitätserkennung (activity recognition) zum Einsatz [SBI⁺15].

Distribution Die Distribution von Kontextdaten stellt den letzten Schritt in-nerhalb des Verarbeitungsprozesses von Kontextdaten dar. Die Kontextbereit-stellung wird in diesem Schritt oft von Konsumenten oder Empfänger der Kon-textdaten aus initiiert. Entsprechend stellt er das Gegenstück zur Kontextak-quisition dar (vergleiche Abschnitt 3.2.1) und bietet dieselben Kommunikati-onsstile an (pull und push).