Mehr Gliederung
This commit is contained in:
parent
e0728e026c
commit
1cc4fc492d
@ -52,7 +52,7 @@
|
||||
}
|
||||
|
||||
% Befehl für TODO-Markierungen
|
||||
\newcommand{\todo}{\textbf{TODO \dots}}
|
||||
\newcommand{\todo}{\emph{Dieser Bereich ist in Bearbeitung.}}
|
||||
|
||||
% Festlegung Kopf- und Fußzeile
|
||||
\defpagestyle{meinstil}{%
|
||||
@ -83,7 +83,7 @@
|
||||
\includegraphics[width=0.2\textwidth]{res/Wortmarke_WI_schwarz.pdf}
|
||||
{ ~ \sffamily
|
||||
\vfill
|
||||
{\Huge\bfseries Verarbeitung von RDF-Ereignisdatenströmen mit C-SPARQL unter Verwendung von Hintergrundwissen}
|
||||
{\Huge\bfseries Verarbeitung von Datenströmen im RDF-Format in Kombination mit Hintergrundwissen in der C-SPARQL-Engine}
|
||||
\bigskip
|
||||
|
||||
{\Large Jan Philipp Timme
|
||||
@ -151,15 +151,18 @@ Diese Arbeit beschäftigt sich mit der Verarbeitung von komplexen Ereignissen (C
|
||||
|
||||
\section{Einführung in Complex Event Processing}
|
||||
|
||||
\todo
|
||||
|
||||
Was ist CEP und warum sollte man es verwenden wollen?
|
||||
|
||||
Wir verarbeiten Ereignisströme und versuchen aus dem großen Rauschen bestimmte Ereignismuster zu erkennen.
|
||||
Und wir wollen kurz-, mittel- oder langfristig bestimmte Werte beobachten und sicherstellen, dass sie innerhalb eines spezifizierten Wertebereichs bleiben.
|
||||
Es ist eine tolle Herangehensweise, um aus großen Datenströmen wesentliche Informationen zu extrahieren - noch bevor ein Mensch diese Daten zu Gesicht bekommt.
|
||||
\todo
|
||||
|
||||
\section{Ereignisquellen}
|
||||
|
||||
\todo
|
||||
|
||||
Ereignisse treten überall auf, wenn man sich darauf einlässt.
|
||||
|
||||
Welche Ereignisse kann man sich denn so vorstellen?
|
||||
@ -177,6 +180,8 @@ Diese hier:
|
||||
|
||||
\section{Ereignisse als Informationsträger}
|
||||
|
||||
\todo
|
||||
|
||||
Alles, was irgendwo passiert liefert Informationen über den Zustand unserer Umgebung.
|
||||
Jede aktuell gemeldete Information ist ein Ereignis. Eine gerade gemessene Temperatur, eine Fehlermeldung einer Werkzeugmaschine oder das Auslösen eines Rauchmelders sind Ereignisse, die einen aktuellen Zustand unserer Welt repräsentieren.
|
||||
|
||||
@ -197,40 +202,31 @@ Ein Ereignis kann beispielsweise so strukturiert sein:
|
||||
|
||||
\section{Ereignisströme als Datenquelle}
|
||||
|
||||
\todo
|
||||
|
||||
Ja, Ereignisse treten auch in Rudeln. Wenn mehrere Ereignisse aneinandergereiht werden, kann man von einem Ereignisstrom sprechen.
|
||||
Anbieter von Daten können anstatt aktueller Messwerte als einzelnes Ereignis natürlich gleich Ereignisströme liefern. Das ist technisch sicherlich auch ganz praktisch, weil Verzicht auf Polling usw.
|
||||
|
||||
\chapter{Anforderungen/Rolle an/von CEP-Engines}
|
||||
|
||||
Dieser Bereich wird hoffentlich etwas kürzer ausfallen - es geht hier vielleicht eher um die Rolle einer CEP-Engine als die Anforderungen.
|
||||
|
||||
Es wäre ja schon wichtig, dass man Hintergrundwissen integriert.
|
||||
Sonst werden die Abfragen so spezifisch und das ist doch doof.
|
||||
|
||||
\section{Kombination von Ereignissen}
|
||||
\chapter{Gegenüberstellung existierender CEP-Engines}
|
||||
|
||||
\todo
|
||||
|
||||
\section{Sliding Windows}
|
||||
Es gibt bereits einige Technologien um Ereignisströme zu verarbeiten.
|
||||
Im Folgenden stelle ich nun ein paar bekannte Systeme kurz vor.
|
||||
|
||||
\todo
|
||||
|
||||
\section{Integration von Hintergrundwissen}
|
||||
Wichtig wären gegebenenfalls diese Kriterien:
|
||||
|
||||
\paragraph{Integration von Hintergrundwissen}
|
||||
Ereignisse kommen ohne Kontext, daher ist es nötig, sie in einen Kontext zu bringen, um etwas mit dem Ereignis anfangen zu können.
|
||||
Um nun den passenden Kontext herzustellen, muss dieses Ereignis also mit weiteren Daten verknüpft werden.
|
||||
Das können andere Ereignisse oder Daten sein, die uns schon bekannt sind - Hintergrundwissen.
|
||||
|
||||
\section{Performance}
|
||||
|
||||
\paragraph{Performance}
|
||||
Auch, wenn einige tausend Ereignisse über einen Datenstrom in der Minute eintreffen muss die Software dennoch sehr zeitnah (im Idealfall sofort) Ergebnisse liefern.
|
||||
|
||||
(Das hier wird später ein Grund sein, weshalb Reasoning nur sehr begrenzt auf Datenströmen stattfinden kann oder aber sehr teuer ist.)
|
||||
|
||||
\chapter{Gegenüberstellung existierender CEP-Engines}
|
||||
|
||||
Es gibt bereits einige Technologien um Ereignisströme zu verarbeiten.
|
||||
Im Folgenden stelle ich nun ein paar bekannte Systeme kurz vor.
|
||||
|
||||
\section{Etalis/EP-SPARQL?}
|
||||
|
||||
@ -242,21 +238,26 @@ Im Folgenden stelle ich nun ein paar bekannte Systeme kurz vor.
|
||||
|
||||
\section{Esper}
|
||||
|
||||
\todo
|
||||
|
||||
Ein Ansatz mit einer eigenen Abfragesprache.
|
||||
Hintergrundwissen etwas fummelig, aber theoretisch möglich. Nur halt nicht in der selben Abfragesprache.
|
||||
|
||||
\section{C-SPARQL}
|
||||
|
||||
\todo
|
||||
|
||||
Verarbeitet Ströme im RDF-Format. Kann Hintergrundwissen im RDF-Format einbeziehen. Wurde in Java implementiert...
|
||||
Es gibt einen W3C-Standard für die Sprache C-SPARQL.
|
||||
Auf das Ding gehe ich gleich näher ein. :-)
|
||||
|
||||
\chapter{Die C-SPARQL-Engine im Detail}
|
||||
|
||||
... und zwar hier.
|
||||
|
||||
\todo
|
||||
|
||||
So, hier kommt dann das, was man so zu C-SPARQL erzählen kann.
|
||||
Dieser Bereich bekommt noch genug Sections für die Features von C-SPARQL
|
||||
|
||||
\section{Abfrage von bestimmten Ereignistypen}
|
||||
|
||||
\todo
|
||||
@ -265,14 +266,19 @@ Auf das Ding gehe ich gleich näher ein. :-)
|
||||
|
||||
\todo
|
||||
|
||||
\chapter{Verarbeitung von RDF-Datenströmen mit C-SPARQL}
|
||||
\chapter{Die C-SPARQL-Engine im Einsatz}
|
||||
|
||||
\todo
|
||||
|
||||
Hier wird jetzt mal wirklich C-SPARQL verwendet.
|
||||
|
||||
\section{RDF-Datenströme}
|
||||
|
||||
\todo
|
||||
|
||||
Spannender ist es, wenn man dann ein Haufen RDF-Tripel reingedrückt bekommt.
|
||||
Die sehen anders aus, sind aber auch toll.
|
||||
Schemenhaft könnten die ja so aussehen:
|
||||
\todo
|
||||
|
||||
Wir können uns diese Datenströme angucken und beispielsweise auf bestimmte Dinge achten.
|
||||
Aber irgendwie ist das nicht so toll, weil unsere Abfragen recht spezifisch sein müssen.
|
||||
@ -282,12 +288,36 @@ Wäre es nicht toll, wenn wir bestimmte Dinge bereits vorher irgendwie da integr
|
||||
|
||||
\todo
|
||||
|
||||
Ich hab noch keine richtig tolle Idee, aber irgendetwas wird es schon werden.
|
||||
Ich hab noch keine richtig tolle Idee, aber irgendetwas wird es schon werden. Im \enquote{temporären Anhang} sind ein paar Notizen hierzu.
|
||||
|
||||
\section{Umsetzung mit C-SPARQL}
|
||||
|
||||
\todo
|
||||
|
||||
\subsection{Nötiger Code}
|
||||
|
||||
\todo
|
||||
|
||||
\subsection{Verwendete C-SPARQL-Abfragen}
|
||||
|
||||
\todo
|
||||
|
||||
\section{Bewertung/Ergebnis}
|
||||
|
||||
\todo
|
||||
|
||||
\chapter{Fazit}
|
||||
|
||||
\todo
|
||||
|
||||
Die Engine macht sich sicher irgendwie gut - mal gucken.
|
||||
|
||||
\chapter{Ausblick}
|
||||
|
||||
\todo
|
||||
|
||||
Vielleicht geht das mit dem Reasoning später ja deutlich besser und so.
|
||||
|
||||
%%% To be removed %%%
|
||||
|
||||
\part{Temporärer Anhang - To be removed}
|
||||
@ -308,7 +338,7 @@ Generell sollen Muster in primitiven Events erkannt und zu komplexen Events zusa
|
||||
\item Betrugserkennung (erst Passwort ändern, dann große Transaktion)
|
||||
\item Steuerung einer Heizungsanlage durch Überwachung von Räumen (Licht an, Fenster auf?)
|
||||
\item Client/Server Interaktion zur Erkennung von Einbruchsversuchen
|
||||
\item
|
||||
\item \dots
|
||||
\end{itemize}
|
||||
|
||||
% Kurzer Test
|
||||
|
||||
Loading…
Reference in New Issue
Block a user