JPT/bachelorthesis
0
0
Fork 0
Code Issues Pull Requests Activity

[TASK] Generic commit.

Browse Source
This commit is contained in:
Jan Philipp Timme 2016-09-21 15:49:45 +02:00
parent 96745d40cb
commit 5912638c6a
1 changed files with 13 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
Bachelorarbeit.tex
View File

@ -474,13 +474,13 @@ Unter Berücksichtigung dieser Kriterien fiel die Wahl auf die CEP-Engine C-SPAR
\chapter{CEP auf RDF-Datenströmen anhand der C-SPARQL Engine}
In diesem Kapitel wird die Verarbeitung von RDF-Datenströmen anhand der CEP-Engine \enquote{C-SPARQL} erläutert.
Nachdem die Wahl der CEP-Engine auf die C-SPARQL-Engine gefallen ist, sollen in diesem Kapitel nun ihre Möglichkeiten zur Verarbeitung von RDF-Datenströmen beleuchtet werden.
\section{Ereignisse}
Ereignisse werden aufgrund der Nutzung von RDF-Datenströmen als Transportmedium nun durch RDF-Tupel beschrieben. Diese tragen neben den typischen Inhalten von Tripeln (Subjekt, Prädikat und Objekt) nun eine vierte Information mit sich: den Zeitstempel zu dem das Ereignis ausgelöst wurde. Da die Tupel nun mit dem Zeitstempel vier Angaben enthalten, werden sie als Quadrupel bezeichnet.
Ereignisse werden aufgrund der Nutzung von RDF-Datenströmen als Transportmedium nun durch RDF-Tupel beschrieben. Diese tragen neben den typischen Inhalten von Tripeln (Subjekt, Prädikat und Objekt) nun eine vierte Information mit sich: den Zeitstempel, zu dem das Ereignis ausgelöst wurde. Da die Tupel nun mit dem Zeitstempel insgesamt vier Angaben enthalten, werden sie als \emph{Quadrupel} bezeichnet.
Um die Ereignisquadrupel trotz identischer Ereignistypen oder Zeitstempel voneinander unterscheiden zu können, ist es nötig, die Ereignisse mit einer eindeutigen ID zu versehen. Um dies zu erreichen, werden die einzelnen Ereignisse als separate Subjekte in RDF repräsentiert. Dadurch erhalten alle Quadrupel eines Ereignisses eine eindeutige Zuordnung zu ihrem Ereignissubjekt.
Um die Ereignisquadrupel trotz identischer Ereignistypen oder Zeitstempel voneinander unterscheiden zu können, ist es nötig, die Ereignisse mit einer eindeutigen ID zu versehen. Um dies zu erreichen, werden die einzelnen Ereignisse als eigene, separate Subjekte in RDF repräsentiert. Dadurch erhalten alle Quadrupel eines Ereignisses eine eindeutige Zuordnung zu ihrem Ereignissubjekt.
Um dies zu verdeutlichen folgt nun ein kleines Beispiel. Gegeben seien zwei beispielhafte Ereignisse mit Statusdaten über einen PKW. Listing~\ref{lst:sample_abstract_event_data} zeigt diese beiden Ereignisse in abstrakter Notation.
\begin{lstlisting}[caption={Zwei Statusereignisse eines PKW in abstrakter Notation},label={lst:sample_abstract_event_data}]
@ -506,29 +506,27 @@ Wie aus Listing~\ref{lst:sample_abstract_event_data} zu erkennen ist, ist jedes
@prefix carOnt: <http://example.org/carSim/carSimulationOntology#> .
@prefix event: <http://example.org/carSim/objects/event#> .
(1344829400) event:324 rdf:type CarStatusEvent .
(1344829400) event:324 rdf:type carOnt:CarStatusEvent .
(1344829400) event:324 carOnt:relatedCar car:0 .
(1344829400) event:324 carOnt:speed 63 .
(1344829405) event:325 rdf:type CarStatusEvent .
(1344829405) event:325 rdf:type carOnt:CarStatusEvent .
(1344829405) event:325 carOnt:relatedCar car:0 .
(1344829405) event:325 carOnt:speed 75 .
\end{lstlisting}
Ereignisdaten, die über RDF-Ereignisdatenströme ausgeliefert werden und zur Verarbeitung einer CEP-Engine zugeführt werden, sehen den in Listing~\ref{lst:sample_abstract_event_data} gezeigten RDF-Quadrupeln von der Struktur her sehr ähnlich.
Über RDF-Ereignisdatenströme ausgelieferte Ereignisdaten, die zur Verarbeitung einer RDF-fähigen CEP-Engine zugeführt werden, sind von der Struktur her angelehnt an die Beispielereignisse aus Listing~\ref{lst:sample_abstract_event_data} aufgebaut.
\section{Sprachkonzepte für CEP-Regeln}
Da Ereignisse nun in Form von RDF-Quadrupeln verarbeitet werden sollen, ... ähm ... ja.
Genau.
Um die Ereignisdatenströme von RDF-Quadrupeln nun in der C-SPARQL-Engine verarbeiten zu können, werden CEP-Regeln benötigt, die im eigentlichen Verarbeitungsprozess verwendet werden, um die Ereignisdaten auszuwerten. Diese Regeln beschreiben Bedingungen, auf die sie matchen, sowie Aktionen, die ausgeführt werden sollen, wenn die Regel matcht. In abstrakter Notation sieht dies wie folgt aus:
\begin{lstlisting}[label={lst:sample_abstract_cep_rule}, caption={Abstrakte Struktur einer CEP-Regel}]
CONDITION (Event1 as e1, Event2 as e2)[within last 10min]
e1.foo > 500 AND e2.origin != "Mars"
ACTION
create new Event3(foo=(e1.baz+e2.baz/3), bar=e2.origin)
\end{lstlisting}
\todo{Dieser Bereich wird definitiv mit abstrakter Sprache und dann konkretem C-SPARQL CSPARQL-Query demonstriert. - das nötige C-SPARQL wurde zuvor ja als Engine der Wahl begründet.}
\begin{itemize}
\item Sliding Windows zur Betrachtung der Ereignisströme
\item Mustererkennung
\item Aggregation von Ereignissen
\end{itemize}
\subsection{CSPARQL als Sprache für CEP-Regeln}
\todo{Und so weiter \dots}