[TASK] Generic commit
This commit is contained in:
parent
a90342efcd
commit
6e95900f4d
@ -7,7 +7,7 @@
|
||||
\KOMAoptions{headinclude} % Fix
|
||||
\usepackage[german]{babel} % Sprachpaket für Deutsch (Umlaute, Trennung,deutsche Überschriften)
|
||||
% Not needed anymore
|
||||
% \usepackage{blindtext}
|
||||
% \usepackage[•]{•}age{blindtext}
|
||||
\usepackage{graphicx,hyperref} % Graphikeinbindung, Hyperref (alles klickbar, Bookmarks)
|
||||
\usepackage{amssymb} % Math. Symbole aus AmsTeX
|
||||
\usepackage[utf8]{inputenc} % Umlaute
|
||||
@ -154,11 +154,9 @@ Hannover, den \today \hfill Unterschrift
|
||||
|
||||
\chapter{Motivation}\label{cpt:motivation}
|
||||
|
||||
\todo{Internet of Things einbringen - was ist es und wofür ist es gut?}
|
||||
Mit der fortschreitenden Digitalisierung von Alltagsgegenständen und ihrer Verbindung mit dem Internet wächst das sogenannte Internet of Things. Dadurch sind auch immer mehr offene Systeme online verfügbar, die ihre Sensordaten und Zustandsinformationen als RDF\footnote{Ressource Description Framework --- Mehr dazu in Kapitel \ref{cpt:basics}}-Datenstrom anbieten. Diese Ereignisdatenströme liefern durchgehend und hochfrequent Ereignisdaten, sodass innerhalb kurzer Zeit sehr große Datenmengen anfallen, die zwecks Extraktion von Informationen und Auslösen von Reaktionen innerhalb kürzester Zeit verarbeitet werden sollen.
|
||||
|
||||
Mit der fortschreitenden Digitalisierung von Alltagsgegenständen und ihrer Verbindung mit dem Internet sind immer mehr offene Systeme online verfügbar, die ihre Sensordaten und Zustandsinformationen als RDF\footnote{Ressource Description Framework - Mehr dazu in Kapitel \ref{cpt:basics}}-Datenstrom anbieten. Diese Ereignisdatenströme liefern durchgehend und hochfrequent Ereignisdaten, sodass innerhalb kurzer Zeit sehr große Datenmengen anfallen.
|
||||
|
||||
Ereignisdaten bilden jeweils kleine Teile der Realität zumindest näherungsweise über die in ihnen enthalten Messdaten und Zustandsinformationen ab, sofern sie nicht bedingt durch technischen Defekt oder Messfehler ungültige Daten enthalten und somit zur Verarbeitung ungeeignet sind. Ein weiteres Problem ist die stark begrenzte Gültigkeit von Ereignisdaten: Oft werden sie schon durch ein neu aufgetretenes Ereignis hinfällig und sind nicht mehr aktuell.
|
||||
Die Ereignisdaten aus diesen Strömen bilden kleine Teile der Realität zumindest nä\-herungs\-wei\-se über die in ihnen enthalten Messdaten und Zustandsinformationen ab, sofern sie nicht bedingt durch technischen Defekt oder Messfehler ungültige Daten enthalten und somit zur Verarbeitung ungeeignet sind. Ein weiteres Problem ist die stark begrenzte Gültigkeit von Ereignisdaten: Oft werden sie schon durch ein neu aufgetretenes Ereignis hinfällig und sind nicht mehr aktuell.
|
||||
|
||||
Ereignisse haben für sich alleine betrachtet eine begrenzte Aussagekraft und Gültigkeit, daher ist es zum höheren Verständnis der dahinter verborgenen Situation notwendig, sie mit den zuvor aufgetretenen Ereignissen in einen Kontext zu setzen. Dadurch können mehrere Ereignisse zu komplexen Ereignissen aggregiert werden und mittels Mustererkennung höherwertige Informationen aus den Ereignissen extrahiert werden.
|
||||
|
||||
@ -166,13 +164,13 @@ Die Integration von Domänenwissen\footnote{Hintergrundwissen für den Kontext d
|
||||
|
||||
Um unter diesen Bedingungen viele Ereignisdatenströme mit hochfrequenten Ereignissen in nahezu Echtzeit zu verarbeiten ist CEP\footnote{Complex-Event-Processing} das Mittel der Wahl: Mit CEP werden die Ereignisse der verschiedenen Datenströme für begrenzte Zeiträume im Speicher vorgehalten und innerhalb von sogenannten Sliding-Windows betrachtet. Dabei können Ereignismuster erkannt werden und verschiedene Ereignisse aggregiert werden um neue komplexe Ereignisse zu erzeugen.
|
||||
|
||||
Ziel dieser Arbeit ist die Einführung in die Konzepte von CEP und RDF, sowie die Demonstration der praktischen Nutzung der CEP-Engine \enquote{C-SPARQL} zur Verarbeitung von RDF-Datenströmen am Beispiel einer Autoverleihgesellschaft zur Überwachung von Leihfahrzeugen. Auch soll ergründet werden, welche technischen Möglichkeiten existieren, um Reasoning auf RDF-Datenströmen zu betreiben - eine Technik, die Erkenntnisse aus den Ereignisströmen durch Anstellung von Schlussfolgerungen auf den Daten der Datenströme extrahiert.
|
||||
Ziel dieser Arbeit ist die Einführung in die Konzepte von CEP und RDF, sowie die Demonstration der praktischen Nutzung der CEP-Engine \enquote{C-SPARQL} zur Verarbeitung von RDF-Datenströmen am Beispiel einer Autoverleihgesellschaft zur Überwachung von Leihfahrzeugen. Auch soll ergründet werden, welche technischen Möglichkeiten existieren, um Reasoning auf RDF-Datenströmen zu betreiben --- eine Technik, die Erkenntnisse aus den Ereignisströmen durch Anstellung von Schlussfolgerungen auf den Daten der Datenströme extrahiert.
|
||||
Diesbezüglich soll ergründet werden, welche CEP-Engines Reasoning bereits implementieren und wie weit ihre technischen Möglichkeiten reichen --- eine große Herausforderung, da die mit einzubeziehenden Ereignisdaten sich kontinuierlich verändern.
|
||||
|
||||
|
||||
\section{Szenario}\label{cpt:scenario}
|
||||
|
||||
\todo{Eventuell platziere ich die Details des Szenarios vor das Konzept-Kapitel und halte die Beschreibung allgemeiner? - Jap, so könnte es gehen. Dann wird hier nur grob erklärt, welche Daten für das Szenario interessant sind; die einzelnen Datenströme und Formate der Ereignisse kommen dann in das Konzept-Kapitel.}
|
||||
\todo{Eventuell platziere ich die Details des Szenarios vor das Konzept-Kapitel und halte die Beschreibung allgemeiner? --- Jap, so könnte es gehen. Dann wird hier nur grob erklärt, welche Daten für das Szenario interessant sind; die einzelnen Datenströme und Formate der Ereignisse kommen dann in das Konzept-Kapitel.}
|
||||
|
||||
Das bereits erwähnte Beispielszenario, welches für diese Arbeit verwendet wird, ist eine Autoverleihgesellschaft, die ihren Fuhrpark überwachen möchte, um ihren Kunden vergünstigte Tarife für verschleißarmes Fahrverhalten anbieten zu können. Weiterhin soll auf plötzlich auftretende Probleme an den Leihwagen möglichst schnell reagiert werden können um Schäden zu begrenzen, gefährliche Situationen zu vermeiden und bei Bedarf dem Kunden unverzüglich einen Ersatzwagen oder weitere Serviceleistungen anbieten zu können. Um dies zu erreichen, werden zwei RDF-Datenströme zur späteren Verarbeitung eingerichtet.
|
||||
|
||||
@ -209,6 +207,9 @@ Um die Ereignisdaten aus den beiden beschriebenen Datenströmen bei der Verarbei
|
||||
|
||||
\todo{Zusammenfassungsüberleitung über das Kapitel}
|
||||
|
||||
\todo{In der Motivation wurde grob erklärt, warum jetzt CEP das Mittel der Wahl sein soll. Aber was bedeutet das eigentlich? Was ist denn CEP und was ist RDF? Das kommt in diesem Kapitel.}
|
||||
|
||||
\todo{Mehr Fachbegriffe nutzen und früher einführen}
|
||||
|
||||
\section{Einführung in das semantische Web}
|
||||
|
||||
@ -283,7 +284,7 @@ CONSTRUCT {
|
||||
|
||||
\begin{itemize}
|
||||
\item Was ist Reasoning?
|
||||
\item Welche Ebenen gibt es? ((OWL, RDFS?) - Unterschied erst bei Verwendung wichtig)
|
||||
\item Welche Ebenen gibt es? ((OWL, RDFS?) --- Unterschied erst bei Verwendung wichtig)
|
||||
\item Warum ist es von Vorteil?
|
||||
\item Mögliche Schwierigkeiten dabei?
|
||||
\item Ontologien beschreiben Zusammenhänge zwischen Objektklassen und Klassen, die auf bestimmte Sachverhalte zutreffen.
|
||||
@ -332,7 +333,50 @@ Ein weiterer Kernaspekt von CEP ist die Mustererkennung in Ereignissen. Aus best
|
||||
Insgesamt liegt die Herausforderung von CEP darin, in kürzester Zeit große Datenströme von Ereignissen mit Hintergrundwissen anzureichern, diese zu höherwertigen Ereignissen zu kombinieren und bestimmte Muster zu finden, sowie die Ergebnisse mit möglichst geringer Verzögerung in Echtzeit ausgeben zu können oder Reaktionen einzuleiten.
|
||||
|
||||
|
||||
\chapter{Gegenüberstellung existierender CEP-Engines}
|
||||
\subsection{Ereignisse als RDF-Datenstrom}
|
||||
|
||||
Um Ereignisse aus verschiedenen Quellen gemeinsam zu verarbeiten ist RDF als kleinster gemeinsamer Nenner für Informationen das Mittel der Wahl. Hierbei werden die Ereignisse gegebenenfalls vorher in das RDF-Format transformiert und als Datenstrom aus RDF-Quadrupeln der CEP-Engine zugeführt. Die Quadrupel führen neben den ereignisrelevanten Informationen zusätzlich noch den Zeitstempel mit, zu dem das Ereignis ausgelöst wurde.
|
||||
Als Abfragesprache für die RDF-Datenströme kommt eine erweiterte Form von SPARQL --- im Folgenden \enquote{CSPARQL} --- zum Einsatz, welche Erweiterungen und Funktionen speziell für die Verarbeitung von RDF-Datenströmen mitbringt. CSPARQL kann die eingehenden RDF-Datenströme in sogenannten \enquote{Sliding Windows} erfassen und ermöglicht die Berücksichtigung der Zeitstempel der Ereignisse innerhalb der Abfrage durch die Bereitstellung von zusätzlichen Sprachkonstrukten und Funktionen. Dabei besteht weiterhin die Möglichkeit, lokal in Form von RDF-Daten vorhandenes Domänenwissen in die Abfrage einzubeziehen und mit den Ereignisdaten zu verknüpfen.
|
||||
|
||||
In Listing~\ref{lst:sample_rdf_event} aufgeführt sind RDF-Tripel, die ein beispielhaftes Zustands-Ereignis aus einem PKW zeigen. Das Prefix \texttt{http://example.org/cars} wurde zu Zwecken der Übersichtlichkeit durch \texttt{cars:} abgekürzt.
|
||||
\begin{lstlisting}[caption={Ereignis im RDF-Format},label={lst:sample_rdf_event}]
|
||||
http://example.org/cars/event#1468064960110 http://example.org/cars#carID http://example.org/cars#8
|
||||
http://example.org/cars/event#1468064960110 http://example.org/cars#currentTemperature "27"^^http://www.w3.org/2001/XMLSchema#integer
|
||||
http://example.org/cars/event#1468064960110 http://example.org/cars#currentSpeed "13"^^http://www.w3.org/2001/XMLSchema#integer
|
||||
\end{lstlisting}
|
||||
|
||||
\todo{Noch ein wenig auf das Listing eingehen, URIs und die fiktiven Prädikate etwas erläutern}
|
||||
|
||||
|
||||
\subsection{SPARQL-Erweiterung zur Verarbeitung von RDF-Datenströmen}
|
||||
|
||||
Der große Vorteil bei der Ereignisverarbeitung mit SPARQL auf RDF-Daten liegt in der Mächtigkeit dieser Abfragesprache: Innerhalb einer einzigen SPARQL-Abfrage ist es möglich Ereignisse aus verschiedenen Quellen miteinander zu kombinieren, direkt mit Hintergrundwissen zu kombinieren, nach eigenen Kriterien zu filtern, einfache Berechnungen anzustellen und aus dem Ergebnis neue Ereignisse beliebiger Struktur zu erzeugen.
|
||||
Somit muss der Anwender neben SPARQL keine weiteren Sprachen lernen oder sich anderweitig mit der Implementierung der Engine auseinandersetzen, sondern kann sich komplett auf die zu analysierenden Ereignisse konzentrieren. Listing~\ref{lst:sample_combine_events_sparql} zeigt einen SPARQL-Query, in dem zwei aufeinanderfolgende Ereignisse mit Angaben zur Momentangeschwindigkeit eines Autos zu einem komplexeren Beschleunigungsereignis kombiniert werden.
|
||||
|
||||
\begin{lstlisting}[caption={Kombination von Ereignissen mit SPARQL},label={lst:sample_combine_events_sparql}]
|
||||
REGISTER QUERY ConstructAcceleratingCars AS
|
||||
PREFIX f: <http://larkc.eu/csparql/sparql/jena/ext#>
|
||||
PREFIX cars: <http://example.org/cars#>
|
||||
CONSTRUCT {
|
||||
[] cars:carID ?car;
|
||||
cars:acceleratedBy ?deltaSpeed .
|
||||
}
|
||||
FROM STREAM <http://example.org/cars> [RANGE 5s STEP 1s]
|
||||
WHERE {
|
||||
?e1 cars:carID ?car ;
|
||||
cars:currentSpeed ?speed1 .
|
||||
?e2 cars:carID ?car ;
|
||||
cars:currentSpeed ?speed2 .
|
||||
BIND (?speed2 - ?speed1 AS ?deltaSpeed)
|
||||
FILTER(f:timestamp(?e1,cars:carID,?car) < f:timestamp(?e2,cars:carID,?car))
|
||||
FILTER(?speed1 < ?speed2)
|
||||
}
|
||||
\end{lstlisting}
|
||||
|
||||
\todo{Streaming-Erweiterungen aus dem Listiung ein wenig hervorheben}
|
||||
|
||||
|
||||
\chapter{Gegenüberstellung existierender CEP-Engines (Stand der Technik für CEP auf RDF-DAtenströmen)}
|
||||
|
||||
\todo{Zusammenfassungsüberleitung über das Kapitel}
|
||||
|
||||
@ -351,7 +395,7 @@ Grobe Eckpunkte zur Orientierung:
|
||||
|
||||
\section*{Anforderungen an CEP-Engines}
|
||||
|
||||
\todo{Die Section raus; Es sind mehr Kriterien/Features als Anforderungen, mal sehen was damit geschehen wird}
|
||||
\todo{Die Section raus; Es sind mehr Kriterien/Features als Anforderungen, mal sehen was damit geschehen wird.}
|
||||
|
||||
\begin{itemize}
|
||||
\item Verarbeitung von mehreren Ereignisströmen
|
||||
@ -416,59 +460,16 @@ Grobe Eckpunkte zur Orientierung:
|
||||
|
||||
\section{Auswahl der Engine für die Arbeit}
|
||||
|
||||
\todo{Warum jetzt eigentlich C-SPARQL? Weil es in Java fährt, auf Jena basiert und somit echt komfortabel in der Handhabung ist. Und trotzdem kommen noch akzeptable Ergebnisse mit minimalem Support für RDFS-Reasoning raus.}
|
||||
\todo{Warum jetzt eigentlich C-SPARQL? Weil es in Java fährt, auf Jena basiert und somit echt komfortabel in der Handhabung ist. Und trotzdem kommen noch akzeptable Ergebnisse mit minimalem Support für RDFS-Reasoning raus. Dadurch ist es für Einsteiger gut geeignet und bietet dennoch schon solide Features durch CSPARQL.}
|
||||
|
||||
|
||||
\chapter{CEP auf RDF-Datenströmen (Konzept)}
|
||||
\chapter{Konzept}
|
||||
|
||||
\todo{Zusammenfassungsüberleitung über das Kapitel}
|
||||
|
||||
\todo{In diesem Kapitel werden abstrakte Condition-Action-Regeln für das Beispielszenario formuliert und dann mit konkreten \enquote{C-SPARQL}-CSPARQL-Queries umgesetzt. }
|
||||
|
||||
|
||||
\section{Ereignisse als RDF-Datenstrom}
|
||||
|
||||
Um Ereignisse aus verschiedenen Quellen gemeinsam zu verarbeiten ist RDF als kleinster gemeinsamer Nenner für Informationen das Mittel der Wahl. Hierbei werden die Ereignisse gegebenenfalls vorher in das RDF-Format transformiert und als Datenstrom aus RDF-Quadrupeln der CEP-Engine zugeführt. Die Quadrupel führen neben den ereignisrelevanten Informationen zusätzlich noch den Zeitstempel mit, zu dem das Ereignis ausgelöst wurde.
|
||||
Als Abfragesprache für die RDF-Datenströme kommt eine erweiterte Form von SPARQL --- im Folgenden \enquote{CSPARQL} --- zum Einsatz, welche Erweiterungen und Funktionen speziell für die Verarbeitung von RDF-Datenströmen mitbringt. CSPARQL kann die eingehenden RDF-Datenströme in sogenannten \enquote{Sliding Windows} erfassen und ermöglicht die Berücksichtigung der Zeitstempel der Ereignisse innerhalb der Abfrage durch die Bereitstellung von zusätzlichen Sprachkonstrukten und Funktionen. Dabei besteht weiterhin die Möglichkeit, lokal in Form von RDF-Daten vorhandenes Domänenwissen in die Abfrage einzubeziehen und mit den Ereignisdaten zu verknüpfen.
|
||||
|
||||
In Listing~\ref{lst:sample_rdf_event} aufgeführt sind RDF-Tripel, die ein beispielhaftes Zustands-Ereignis aus einem PKW zeigen. Das Prefix \texttt{http://example.org/cars} wurde zu Zwecken der Übersichtlichkeit durch \texttt{cars:} abgekürzt.
|
||||
\begin{lstlisting}[caption={Ereignis im RDF-Format},label={lst:sample_rdf_event}]
|
||||
http://example.org/cars/event#1468064960110 http://example.org/cars#carID http://example.org/cars#8
|
||||
http://example.org/cars/event#1468064960110 http://example.org/cars#currentTemperature "27"^^http://www.w3.org/2001/XMLSchema#integer
|
||||
http://example.org/cars/event#1468064960110 http://example.org/cars#currentSpeed "13"^^http://www.w3.org/2001/XMLSchema#integer
|
||||
\end{lstlisting}
|
||||
|
||||
\todo{Noch ein wenig auf das Listing eingehen, URIs und die fiktiven Prädikate etwas erläutern}
|
||||
|
||||
|
||||
\section{SPARQL-Erweiterung zur Verarbeitung von RDF-Datenströmen}
|
||||
|
||||
Der große Vorteil bei der Ereignisverarbeitung mit SPARQL auf RDF-Daten liegt in der Mächtigkeit dieser Abfragesprache: Innerhalb einer einzigen SPARQL-Abfrage ist es möglich Ereignisse aus verschiedenen Quellen miteinander zu kombinieren, direkt mit Hintergrundwissen zu kombinieren, nach eigenen Kriterien zu filtern, einfache Berechnungen anzustellen und aus dem Ergebnis neue Ereignisse beliebiger Struktur zu erzeugen.
|
||||
Somit muss der Anwender neben SPARQL keine weiteren Sprachen lernen oder sich anderweitig mit der Implementierung der Engine auseinandersetzen, sondern kann sich komplett auf die zu analysierenden Ereignisse konzentrieren. Listing~\ref{lst:sample_combine_events_sparql} zeigt einen SPARQL-Query, in dem zwei aufeinanderfolgende Ereignisse mit Angaben zur Momentangeschwindigkeit eines Autos zu einem komplexeren Beschleunigungsereignis kombiniert werden.
|
||||
|
||||
\begin{lstlisting}[caption={Kombination von Ereignissen mit SPARQL},label={lst:sample_combine_events_sparql}]
|
||||
REGISTER QUERY ConstructAcceleratingCars AS
|
||||
PREFIX f: <http://larkc.eu/csparql/sparql/jena/ext#>
|
||||
PREFIX cars: <http://example.org/cars#>
|
||||
CONSTRUCT {
|
||||
[] cars:carID ?car;
|
||||
cars:acceleratedBy ?deltaSpeed .
|
||||
}
|
||||
FROM STREAM <http://example.org/cars> [RANGE 5s STEP 1s]
|
||||
WHERE {
|
||||
?e1 cars:carID ?car ;
|
||||
cars:currentSpeed ?speed1 .
|
||||
?e2 cars:carID ?car ;
|
||||
cars:currentSpeed ?speed2 .
|
||||
BIND (?speed2 - ?speed1 AS ?deltaSpeed)
|
||||
FILTER(f:timestamp(?e1,cars:carID,?car) < f:timestamp(?e2,cars:carID,?car))
|
||||
FILTER(?speed1 < ?speed2)
|
||||
}
|
||||
\end{lstlisting}
|
||||
|
||||
\todo{Streaming-Erweiterungen aus dem Listiung ein wenig hervorheben}
|
||||
|
||||
|
||||
\section{Resoning auf RDF-Datenströmen?}
|
||||
|
||||
\begin{itemize}
|
||||
@ -481,7 +482,7 @@ WHERE {
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\chapter{Nutzung der Engine C-SPARQL (Implementation)}
|
||||
\chapter{Implementierung mit der C-SPARQL Engine}
|
||||
|
||||
\todo{Zusammenfassungsüberleitung über das Kapitel}
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user