%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Setup des Dokuments
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\documentclass[12pt,DIV14,BCOR10mm,a4paper,twoside,parskip=half-,headsepline,headinclude]{scrreprt} % Grundgröße 12pt, zweiseitig
% Packages from template
\usepackage[headsepline,automark]{scrpage2} % Seitenköpfe automatisch
\KOMAoptions{headinclude} % Fix
\usepackage[german]{babel} % Sprachpaket für Deutsch (Umlaute, Trennung,deutsche Überschriften)
\usepackage{graphicx,hyperref} % Graphikeinbindung, Hyperref (alles klickbar, Bookmarks)
\usepackage{amssymb} % Math. Symbole aus AmsTeX
\usepackage[utf8]{inputenc} % Umlaute
% Custom packages
\usepackage[autostyle=true,german=quotes]{csquotes} % Anführungszeichen mit \enquote{}
\usepackage{textcomp} % Zusätzliches Package für °C
\usepackage{listings} % Codesnippets
\usepackage{scrhack} % Hack for lstlisting i suspect :-/
\usepackage{xcolor}
\usepackage{verbatim} % für comment-environment
% Setup für Codeblocks
\lstset{
	% Optionen
	breaklines=true,
	breakatwhitespace=true,
	breakautoindent=true,
	frame=single,
	%framexleftmargin=19pt,
	inputencoding=utf8,
	%language=awk,
	%numbers=left,
	%numbersep=8pt,
	showspaces=false,
	showstringspaces=false,
	tabsize=1,
	%xleftmargin=19pt,
	captionpos=b,
	% Styling
	basicstyle=\footnotesize\ttfamily,
	commentstyle=\footnotesize,
	keywordstyle=\footnotesize\ttfamily,
	numberstyle=\footnotesize,
	stringstyle=\footnotesize\ttfamily,
}
% Hack für Sonderzeichen in Codeblocks
\lstset{literate=%
    {Ö}{{\"O}}1
    {Ä}{{\"A}}1
    {Ü}{{\"U}}1
    {ß}{{\ss}}1
    {ü}{{\"u}}1
    {ä}{{\"a}}1
    {ö}{{\"o}}1
    {°}{{${^\circ}$}}1
}

% Befehl für TODO-Markierungen
\newcommand{\todo}[1]{\textcolor{blue}{\emph{TODO: #1}}}

% Befehl für Entwürfe und grobe Pläne
\newenvironment{draft}{\par\color{orange}\begin{center}Entwurf / Konzept\end{center}\hrule}{\hrule\par}

% Broken citation needs broken command
\newcommand\mathplus{+}

% Festlegung Kopf- und Fußzeile     
\defpagestyle{meinstil}{%
	{\headmark \hfill}
	{\hfill \headmark}
	{\hfill \headmark\hfill}
	(\textwidth,.4pt)
}{%
	(\textwidth,.4pt)
	{\pagemark\hfill Jan Philipp Timme}
	{Version 0.4 vom \today \hfill \pagemark}
	{Version 0.4 vom \today \hfill \pagemark}
}
\pagestyle{meinstil}

\raggedbottom

\renewcommand{\topfraction}{1}
\renewcommand{\bottomfraction}{1}
 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Beginn des Dokuments (Titelseite und der ganze Krempel)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{document}

% Titelseite
\thispagestyle{empty}
\includegraphics[width=0.2\textwidth]{res/Wortmarke_WI_schwarz.pdf}
{ ~ \sffamily
	\vfill
	{\Huge\bfseries CEP auf RDF-Datenströmen (unter Integration von Hin\-ter\-grund\-wis\-sen) in der C-SPARQL-Engine}
	\bigskip

	{\Large Jan Philipp Timme
		\\[2ex]
		Bachelor-Arbeit im Studiengang "`Angewandte Informatik"'
		\\[5ex]
		\today
	}
}
\vfill
	~ \hfill
	\includegraphics[height=0.3\paperheight]{res/H_WI_Pantone1665.pdf}
\vspace*{-3cm}

% Seite mit Personen und Selbstständigkeitserklärung
\newpage \thispagestyle{empty}
\begin{tabular}{ll}
{\bfseries\sffamily Autor} &  Jan Philipp Timme \\ 
	& 1271449 \\
	& jan-philipp.timme@stud.hs-hannover.de \\[5ex]
{\bfseries\sffamily Erstprüfer} & Prof. Dr. Jürgen Dunkel \\
	& Abteilung Informatik, Fakultät IV \\
	& Hochschule Hannover \\
	& juergen.dunkel@hs-hannover.de \\[5ex]
{\bfseries\sffamily Zweitprüfer} & Jeremias Dötterl, M. Sc. \\
	& Abteilung Informatik, Fakultät IV \\
	& Hochschule Hannover \\
	& jeremias.doetterl@hs-hannover.de
\end{tabular}

\vfill

% fett und zentriert in der Minipage
\begin{center} \sffamily\bfseries Selbständigkeitserklärung \end{center}

Hiermit erkläre ich, dass ich die eingereichte Bachelor-Arbeit
selbständig und ohne fremde Hilfe verfasst, andere als die von mir angegebenen Quellen
und Hilfsmittel nicht benutzt und die den benutzten Werken wörtlich oder
inhaltlich entnommenen Stellen als solche kenntlich gemacht habe. 
\vspace*{7ex}

Hannover, den \today \hfill Unterschrift

\pdfbookmark[0]{Inhalt}{contents}
% Inhaltsverzeichnis
\tableofcontents
% Abbildungsverzeichnis
\listoffigures
% Codeverzeichnis
\lstlistoflistings
% Tabellenverzeichnis
\listoftables

\newpage

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% Hier geht es richtig los mit dem Text!
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{Motivation}\label{cpt:motivation}

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 \emph{RDF}\footnote{Resource 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 in kürzester Zeit verarbeitet werden sollen. 

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 vor der weiteren Verarbeitung herausgefiltert werden sollten. 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 neben einer begrenzten Gültigkeit eine begrenzte Aussagekraft, daher ist es zum höheren Verständnis der dahinter verborgenen Situation notwendig, sie mit zuvor aufgetretenen Ereignissen in einen Kontext zu setzen. Dadurch können mehrere kleine, hochfrequent auftretende Ereignisse zu einzelnen, niederfrequent auftretenden komplexen Ereignissen aggregiert werden und mittels Mustererkennung höherwertige Informationen aus den Ereignissen extrahiert werden.

\todo{GRAFIK: viele kleine hochfrequente vs wenige große niederfrequente Events}

Die Integration von \emph{Domänenwissen}\footnote{Hintergrundwissen für den Kontext der Ereignisverarbeitung, verändert sich während der Verarbeitung nur selten} ist ein weiterer Schritt, der die Brücke zwischen den aus komplexen Ereignissen gewonnenen Kenntnissen und bereits bekannten Fakten schlagen soll, um die gewonnenen Kenntnisse in einen eindeutigen Zusammenhang stellen und eine eindeutige Interpretation zu ermöglichen.

Um unter diesen Bedingungen viele Ereignisdatenströme mit hochfrequenten Ereignissen in nahezu Echtzeit zu verarbeiten ist \emph{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 \emph{Sliding-Windows}\footnote{Mehr dazu in Kapitel~\ref{cpt:cep_intro}} betrachtet. Dabei können Ereignismuster erkannt werden und verschiedene Ereignisse aggregiert werden um neue komplexe Ereignisse zu erzeugen.

\todo{GRAFIK: Mustererkennung aus Sliding Window + Generation von neuem Event daraus}

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 \emph{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}
Das 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.

\paragraph{Anforderungen}
Um die Ziele der Autoverleihgesellschaft erreichen zu können, sollen folgende Situationen erkannt werden:
\begin{itemize}
\item Starker Verschleiß eines Fahrzeugs durch unsachgemäßes Fahrverhalten
\item Wartungsbedarf am Fahrzeug, wie beispielsweise:
\begin{itemize}
\item Schäden an den Reifen
\item Vom Fahrzeug selbst erkannte Probleme
\end{itemize}
\item Eintritt eines Unfalls
\item Unbeabsichtigtes Wegrollen von abgestellten Fahrzeugen
\end{itemize}

Um diese Situationen zu erkennen, sollen zwei RDF-Ereignisdatenströme zur späteren Verarbeitung eingerichtet werden und eine Sammlung von Fakten in lokalem Domänenwissen modelliert werden. Diese werden im Folgenden vorerst nur grob beschrieben.

\paragraph{Statusdatenstrom der PKW}
Über diesen Datenstrom sollen die einzelnen PKW kontinuierlich ihre Statuswerte melden:
\begin{itemize}
\item PKW verschlossen (ja/nein)
\item Status des Motors (an/aus)
\item Status der Handbremse (angezogen/gelöst)
\item Momentangeschwindigkeit in km/h
\item Drehzahl des Motors
\item Reifendrücke der Reifen in bar
\end{itemize}
Besonders wichtige Ereignisse, wie das Aufleuchten der Motorkontrollleuchte oder das Auslösen des Airbags, sollen über diesen Datenstrom separat von den Statusdaten gemeldet werden.

\paragraph{Interaktionsstrom der Kunden}
Wird einem Kunden ein PKW zugewiesen oder gibt ein Kunde einen geliehenen PKW wieder zurück, so soll hierfür ein Ereignis in diesen Datenstrom eingespeist werden. Diese Ereignisse sollen immer die eindeutige Kundennummer und die Nummer des geliehenen Fahrzeugs enthalten, um eine eindeutige Zuordnung vornehmen zu können.

\paragraph{Domänenwissen}
Um die Ereignisdaten aus den beiden beschriebenen Datenströmen bei der Verarbeitung in einen eindeutigen Kontext setzen zu können, wird lokal verfügbares Hintergrundwissen benötigt. Es soll die Zuordnung von Kunden zu den von ihnen geliehenen PKW aufbauen, die einzelnen PKW konkreten Automodellen zuordnen und somit eine konkrete Interpretation der von den PKW gemeldeten Daten ermöglichen.

Das Domänenwissen soll in diesem Szenario folgende Informationen enthalten:
\begin{itemize}
\item Eindeutige Zuordnung von Kundennummer zu einem Kunden
\item Kundendaten wie Name und Telefonnummer
\item Eindeutige Zuordnung von Fahrzeugnummer zu Automodell
\item Wissen über Automodelle:
	\begin{itemize}
	\item Empfohlene Motordrehzahlbereiche für verschleißarmes Fahren
	\item Vorgeschriebener Reifendruck
	\end{itemize}
\end{itemize}

\todo{GRAFIK: Grobes Informationsnetzwerk zur Veranschaulichung der Zusammenhänge zwischen den drei Elementen (Ströme + Hintergrundwissen).}


\chapter{Grundlagen}\label{cpt:basics}

Nachdem in Kapitel~\ref{cpt:motivation} das Vorhaben dieser Arbeit grob beschrieben wurde, folgt nun eine Einführung in die dafür benötigten Grundlagen. Da die später zu verarbeitenden Ereignisdatenströme im RDF-Format vorliegen werden, soll zunächst eine Einführung in das semantische Web zeigen, wie RDF zur Modellierung und Beschreibung von Wissen eingesetzt werden kann, und welche Möglichkeiten dadurch geboten werden. Anschließend sollen die grundlegenden Konzepte von CEP erläutert mit Hinblick auf die Verarbeitung von RDF-Datenströmen erläutert werden.


\section{Einführung: RDF im semantischen Web}

Das sogenannte \enquote{semantische Web} ist ein großes Anwendungsgebiet für RDF-Daten und deren Verlinkung. In diesem Abschnitt soll erläutert werden, was RDF ist, wofür es eingesetzt wird, und wie man in RDF vorliegende Daten verwenden und weiter verarbeiten kann.


\subsection{RDF im semantischen Web}\label{cpt:rdf-semantic-web}

Das Resource Description Framework (RDF) wird im semantischen Web zur Modellierung und Repräsentation von Wissen verwendet. RDF-Daten bestehen aus einer Menge von Tripeln, welche sich aus den drei Komponenten Subjekt, Prädikat und Objekt in genau dieser Abfolge zusammensetzen um eine Aussage zu formen. Jeder dieser drei Bestandteile eines Tripels kann durch einen eindeutigen Uniform Resource Identifier (URI\footnote{Der URI wird in RFC 3986 beschrieben. Anstelle eines URI kann auch ein IRI (Internationalized Resource Identifier) verwendet werden --- die internationalisierte Form des URI nach RFC 3987.}) identifiziert werden. Lediglich in der Position \enquote{Objekt} eines Tripels kommen auch sehr häufig sogenannte \emph{Literale} vor um konkrete Datenwerte beispielsweise in Form von Zeichenketten oder Ganzzahlen zu repräsentieren.
\begin{lstlisting}[caption={Ein RDF-Tripel},label={lst:sample_rdf_triple}]
<http://example.org/carSim/objects/Car#23>	<http://example.org/carSim/carSimulationOntology#isCarModel>	<http://example.org/carSim/objects/CarModel#42> .
\end{lstlisting}

Das in Listing~\ref{lst:sample_rdf_triple} enthaltene Tripel ordnet das Car-Subjekt \texttt{\#23} über das Prädikat \texttt{isCarModel} dem Objekt CarModell \texttt{\#42} zu.

\todo{GRAFIK: zwei Elipsen und ein Pfeil, alle mit je S/P/O beschriftet zur Verdeutlichung.}

\paragraph{Turtle-Notation mit Prefixen}
Wie anhand des Beispiels aus Listing~\ref{lst:sample_rdf_triple} erkennbar ist, ist die explizite Notation für Tripel aufgrund der häufigen Nennung von vollständigen URIs wenig platzsparend und für große Datenmengen somit nicht empfehlenswert. Hierfür bietet sich die Nutzung von Prefixen an, die nach einmaliger Definition innerhalb eines Kontextes (zum Beispiel einer Datei) verwendet werden können.
Listing~\ref{lst:sample_rdf_triple_with_prefix} zeigt die Notation von Tripeln im Turtle\footnote{Siehe auch die Spezifikation der Turtle-Notation nach \cite{w3c:turtle}}-Format unter Verwendung von Prefixen.
\begin{lstlisting}[caption={Das Tripel aus Listing~\ref{lst:sample_rdf_triple} mit Prefixen},label={lst:sample_rdf_triple_with_prefix}]
@prefix car: <http://example.org/carSim/objects/Car#> .
@prefix carModel: <http://example.org/carSim/objects/CarModel#> .
@prefix carOnt: <http://example.org/carSim/carSimulationOntology#> .

car:23	carOnt:isCarModel	carModel:42 .
\end{lstlisting}
Über Prädikate können diesem Subjekt mit Spezifikation im Objekt-Teil des Tripels bestimmte Attribute mit Werten zugesprochen werden oder Verknüpfungen mit anderen Subjekten hergestellt werden.

Aufgrund der Flexibilität dieser Struktur ist es möglich, nahezu jede Art von Informationen auf Tripel abzubilden, wie Listing~\ref{lst:sample_rdf_data} an einem Beispiel zeigt.
\begin{lstlisting}[caption={RDF-Daten beschreiben einen Fahrer, ein PKW und dessen Modell},label={lst:sample_rdf_data}]
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix car: <http://example.org/carSim/objects/Car#> .
@prefix carModel: <http://example.org/carSim/objects/CarModel#> .
@prefix driver: <http://example.org/carSim/objects/Driver#> .
@prefix carOnt: <http://example.org/carSim/carSimulationOntology#> .

car:0	rdf:type	carOnt:Car .
car:0	carOnt:isCarModel	carModel:0 .

carModel:0	rdf:type	carOnt:CarModel .
carModel:0	carOnt:minimumMotorRPM	2000 .
carModel:0	carOnt:maximumMotorRPM	4300 .
carModel:0	carOnt:minimumTirePressure	2.9 .
carModel:0	carOnt:maximumTirePressure	3.2 .
carModel:0	carOnt:requiresDriverLicense	"B"^^xsd:string

driver:0	rdf:type	carOnt:Driver .
driver:0	carOnt:hasName	"Max Mustermann"^^xsd:string .
driver:0	carOnt:hasPhoneNumber	"+49 111 123456789"^^xsd:string .
driver:0	carOnt:hasDriverLicense	"B"^^xsd:string .

car:0	carOnt:isDrivenBy	driver:0 .
driver:0	carOnt:drives	car:0
\end{lstlisting}

\paragraph{Graphen}
Da innerhalb des semantischen Web angestrebt wird, in RDF vorliegende Informationen gemeinsam zu nutzen und miteinander zu vernetzen zu können, werden RDF-Tripel meist als Quadrupel (oder kurz \enquote{Quad}) gehandhabt, in denen als zusätzliche Information der sogenannte Graph genannt wird, in dem die Tripel enthalten sind. Ein Graph wird durch eine URI identifiziert und dient als Namensraum für die Tripel, die er enthält. Dies vereinfacht die gleichzeitige Nutzung von mehreren Datenquellen, da jedes Tripel eindeutig einem Graphen zugeordnet werden kann und innerhalb von Abfragen spezifisch Tripel aus verschiedenen Graphen selektiert werden können.

\todo{GRAFIK: Verbildlichung durch mehrere mit URI gekennzeichneten Container, die ein paar Tripel enthalten, die aufeinander verweisen.}

\paragraph{RDF-Schema}
Das \enquote{RDF-Schema} (kurz RDFS\footnote{Für eine detailreiche Einführung in RDFS siehe auch \cite{hitzler:semanticweb}[Kapitel 3.4]}) dient zur Spezifikation von Schemawissen durch die Definition von Objektklassen und Prädikaten, welche in hierarchischen Verhältnissen zueinander stehen können\footnote{Mittels \texttt{rdfs:subclassOf} und \texttt{rdfs:subpropertyOf} können hierarchische Verhältnisse zwischen verschiedene Properties beziehungsweise Objektklassen definiert werden.}. Betrachtet man beispielsweise die Daten aus Listing~\ref{lst:sample_rdf_data}, so ist für die Verwendung des Prädikats \texttt{carOnt:drives} in diesem Kontext offensichtlich, dass es nur zusammen mit einem Subjekt der Klasse \texttt{Driver} und einem Objekt der Klasse \texttt{Car} verwendet werden sollte um eine sinnvolle Aussage zu ergeben. Eine solche Regel kann mit Hilfe von RDFS definiert werden, wie Listing~\ref{lst:sample_rdfs_data} zeigt.
\begin{lstlisting}[caption={Definition der Klassen \texttt{Car} und \texttt{Driver} sowie des Prädikats \texttt{drives} in RDFS},label={lst:sample_rdfs_data}]
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix carOnt: <http://example.org/carSim/carSimulationOntology#> .

carOnt:Car	rdf:type	rdfs:class .
carOnt:Driver	rdf:type	rdfs:class .

carOnt:drives	rdf:type	rdf:Property .
carOnt:drives	rdfs:domain	carOnt:Driver .
carOnt:drives	rdfs:range	carOnt:Car .
\end{lstlisting}
In Listing~\ref{lst:sample_rdfs_data} werden zunächst die beiden Klassen \texttt{carOnt:car} und \texttt{carOnt:Driver} definiert. Im darauf folgenden Absatz wird dann das Merkmal \texttt{carOnt:drives} definiert und über \texttt{rdfs:domain} auf Subjekte der Klasse \texttt{Driver} und mit \texttt{rdfs:range} auf Objekte der Klasse \texttt{Car} eingeschränkt. Trifft man in diesem Kontext nun Tripel mit einem Prädikat \texttt{carOnt:drives} an, so kann man anhand der zugehörigen RDFS-Daten bereits erkennen, womit man es zutun hat.

\paragraph{OWL-Ontologien}
In OWL (Web Ontology Language) formulierte Ontologien werden im semantischen Web sehr häufig zur Strukturierung von RDF-Daten verwendet. Ähnlich wie RDFS definieren OWL-Ontologien ein Vokabular mit logischen Do\-mä\-nen\-objekt\-klas\-sen und bestimmt für diese Objektklassen Prädikate und Attribute, um bestimmte Sachverhalte eindeutig abbilden zu können. Eine Ontologie für Listing~\ref{lst:sample_rdf_data} würde beispielsweise eine Objektklasse \texttt{Driver} definieren, auf welche das eigens hierfür definierte Prädikat \texttt{hasName} mit einem Attribut vom Typ \texttt{xsd:string} angewandt werden kann. Durch die Möglichkeiten dieser Restriktionen können RDF-Daten aus der Welt einer Ontologie --- ähnlich wie bei einem relationalen Datenbankschema --- eindeutig strukturiert werden.

\paragraph{Open World Assumption}
Es ist wichtig hervorzuheben, dass für in RDF abgebildete Daten nahezu immer die Annahme gilt, dass diese Daten nicht vollständig sind und somit nicht alle Fakten wirklich bekannt sind. Die meisten Ontologien respektieren diese Annahme und verzichten auf die Definition von expliziten Regeln, die über die konkrete Bedeutung der Abwesenheit von bestimmten Fakten entscheiden würden. (In der Welt der relationalen Datenbanksysteme gibt es eine ähnliche Problematik in Zusammenhang mit der Verwendung des Schlüsselworts \texttt{NULL}.)

Natürlich ist es möglich, mehrere verschiedene Ontologien gleichzeitig zu verwenden. Diese Flexibilität ermöglicht beispielsweise, dass eine bereits in RDF abgebildete Person durch beliebige Informationen mit weiteren Ontologien ergänzt werden kann, oder dass die Informationen einer abgebildeten Person in verschiedenen, für andere Parteien geläufigen Strukturen verfügbar gemacht werden können. Auch kann innerhalb einer Ontologie auf Objektklassen und Attribute zurückgegriffen werden, die in anderen Ontologien definiert werden. Dies ermöglicht neben Erweiterungen für spezifische Zwecke auch das Übersetzen von Wissen zwischen verschiedenen Ontologien.

\paragraph{ABox und TBox}
Bei der Modellierung von Wissen mit Hilfe von Beschreibungslogiken, zu denen auch OWL und RDFS zählen, werden die formulierten Aussagen in zwei Gruppen unterteilt\cite{hitzler:semanticweb}[Kapitel 6.1]: Die Assertion Box (ABox) und die Terminology Box (TBox). Während die TBox Aussagen mit terminologischem Schemawissen wie Definitionen von Objektklassen, Prädikaten und ihren Verhältnissen zueinander enthält, beinhaltet die ABox sogenanntes \emph{assertionales Instanzwissen}\cite{hitzler:semanticweb}[Kapitel 6.1], welches aus Aussagen über Klasseninstanzen und deren Merkmale und Beziehungen besteht, in denen das durch die TBox definierte Vokabular genutzt wird.

\todo{GRAFIK: Ein wenig visualisiertes Wissen, welches TBox und ABox-Inhalte getrennt voneinander darstellt. (Eine Ebene mit Klassen und Attributen, eine andere Ebene mit konkreten Klasseninstanzen und deren Merkmalen)}


\subsection{Abfrage von RDF-Daten via SPARQL}\label{cpt:rdf-sparql}

Die Abfrage von Wissen aus RDF-Daten erfolgt über die Abfragesprache \emph{SPARQL} (\enquote{SPARQL Protocol And RDF Query Language}), welche in diesem Abschnitt grob erläutert wird. Eine detaillierte Beschreibung von SPARQL ist unter \cite{w3c:sparql} nachzulesen.

Im Gegensatz zu Abfragesprachen von relationalen Datenbanksystemen wie SQL ist es mit SPARQL möglich, Daten über verschiedene Datenquellen wie Tripel- oder Quadstores\footnote{Analog zu relationalen Datenbanksystemen für Relationen ein Speicher für RDF-Tripel beziehungsweise RDF-Quads} hinweg miteinander zu verknüpfen. Auch ist im Gegensatz zu SQL keine spezielle Anpassung der Abfragen an ein Datenbankschema notwendig; lediglich die Art und Weise, wie die angeforderten Daten miteinander in Verbindung stehen, ist für SPARQL-Abfragen wichtig. Kenntnisse über das verwendete Vokabular (RDF-Schema oder OWL-Ontologien) können jedoch bei der Formulierung der Abfragen hilfreich sein. Im Folgenden zeigt Listing~\ref{lst:sample_sparql_query} eine einfache Abfrage auf den Daten aus Listing~\ref{lst:sample_rdf_data}.
\begin{lstlisting}[caption={Abfrage der maximal zulässigen Motordrehzahl des Auto-Subjektes Nr. 0 aus Daten von Listing~\ref{lst:sample_rdf_data}},label={lst:sample_sparql_query}]
PREFIX carOnt: <http://example.org/carSim/carSimulationOntology#>
PREFIX car: <http://example.org/carSim/objects/Car#>

SELECT ?maxMotorRPM
WHERE {
	car:0	carOnt:isCarModel	?carModel .
	?carModel	carOnt:maximumMotorRPM	?maxMotorRPM .
}
\end{lstlisting}
\paragraph{Selektion von Daten}
Listing~\ref{lst:sample_sparql_query} zeigt, dass SPARQL in der groben Grundstruktur eine Ähnlichkeit zu SQL aufweist; allerdings sind bedingt durch die Struktur der Daten (Relationen bei SQL gegenüber Tripel und Quadrupel bei SPARQL) große Unterschiede in der Gestaltung der Abfragen zu finden. Zunächst werden analog zur Turtle-Notation Prefixe notiert, die innerhalb der Abfrage verwendet werden sollen. In der \texttt{WHERE}-Klausel werden Tripel mit Platzhaltern verwendet, um aus dem vorhandenen Datenbestand die Tripel zu isolieren, die auf das angegebene Muster passen. So wird in diesem Beispiel zunächst ein Tripel gesucht, welches als Subjekt \texttt{car:0} gesetzt hat und das Prädikat \texttt{carOnt:isCarModel} verwendet, welches auf das zu dem Auto zugehörige Automodell-Subjekt zeigt. Ergibt sich ein Treffer, so wird der Objekt-Teil des gefundenen Tripels in den Platzhalter \texttt{?carModel} eingefügt und für die Suche des zweiten Tripels des SPARQL-Queries verwendet.

Für das gefundene \texttt{?carModel} wird nun ein Tripel gesucht, welches für \texttt{?carModel} das Prädikat \texttt{carOnt:maximumMotorRPM} nutzt, um die Angabe der maximalen Drehzahl für dieses Automodell zu definieren. Wird hierfür ebenfalls ein Treffer gelandet, so wird der Platzhalter \texttt{?maxMotorRPM} mit dem dazugehörigen Wert gefüllt und kann dann in der \texttt{SELECT}-Klausel selektiert werden. Für jede Tripelkombination, die auf die in der \texttt{WHERE}-Klausel formulierten Beschreibung passt, ergibt sich nun ein Ergebnis, für welches die in der \texttt{SELECT}-Klausel angegebenen Felder zurückgegeben werden --- in diesem Fall also lediglich ein Ergebnis mit dem Wert \enquote{4300}.

\paragraph{Konstruktion von Daten durch Abfragen}
Neben \texttt{SELECT} unterstützt SPARQL auch das Schlüsselwort \texttt{CONSTRUCT}. Dieses ermöglicht die direkte Konstruktion von neuen Tripeln aus vorgegebenen Tripeln mit Platzhaltern, welche mit den Ergebnissen der Abfrage gefüllt werden. Listing~\ref{lst:sample_sparql_construct} zeigt die beispielhafte Erzeugung von Tripeln auf Basis der Daten aus Listing~\ref{lst:sample_rdf_data}, welche über das Prädikat \texttt{carOnt:motorRPMTolerance} Auskunft über die Größe des akzeptablen Drehzahlbereiches der Automodelle geben sollen.
\begin{lstlisting}[caption={Konstruktion von neuen Tripeln auf Basis des Wissens aus Listing~\ref{lst:sample_rdf_data}},label={lst:sample_sparql_construct}]
PREFIX carOnt: <http://example.org/carSim/carSimulationOntology#>
PREFIX car: <http://example.org/carSim/objects/Car#>

CONSTRUCT {
	?carModel	carOnt:motorRPMTolerance	?rpmTolerance .
} WHERE {
	?carModel	rdf:type	carOnt:CarModel .
	?carModel	carOnt:minimumMotorRPM	?minMotorRPM .
	?carModel	carOnt:maximumMotorRPM	?maxMotorRPM .
	BIND(?maxMotorRPM - ?minMotorRPM AS ?rpmTolerance) .
}
\end{lstlisting}
Wie in Listing~\ref{lst:sample_sparql_construct} gezeigt, können einfache Operationen in SPARQL-Abfragen durchgeführt werden, deren Ergebnisse über die \texttt{BIND}-Anweisung in einen vorgegebenen Platzhalter \texttt{?rpmTolerance} eingesetzt werden. In diesem Beispiel wurde die Differenz zwischen der maximalen und der minimalen empfohlenen Motordrehzahl eines Automodells ausgerechnet und ein neues Tripel mit dieser Information generiert.


\subsection{Schlussfolgerungen auf RDF-Daten}\label{cpt:reasoning}

\todo{Etwas mehr Inhalt, an Beispielszenario annähern}

\begin{itemize}
\item Was ist Reasoning?
\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.
\item Naja, jedenfalls kann man da schonmal autocomplete-mäßig rechnen (RDFS)
\item Und dann kann man noch reguläre Schlussfolgerungen fahren in der Richtung OWL
\item Warum ist Reasoning überhaupt wichtig und sinnvoll?
\end{itemize}

Durch den Einsatz von Ontologien ergibt sich die Möglichkeit, auf RDF-Daten Ontologie-gestützt Schlussfolgerungen anstellen zu können (Reasoning). In diesem Prozess werden aus den in RDF vorliegenden Fakten (Assertion Box) und den in den verwendeten Ontologien definierten Objektklassen, Regeln und Zusammenhängen (Terminology Box) neues Wissen abgeleitet \cite{hitzler:semanticweb} und die lokale Datenbasis damit angereichert. So können beispielsweise implizite Klassentypen errechnet werden (\enquote{Ein PKW ist auch ein Fahrzeug}), oder regelbasierte Zugehörigkeiten zu Objektklassen ermittelt werden: Die Aussagen \enquote{Der PKW x rollt.} und \enquote{Der PKW x ist abgeschlossen.} können zu der Folgerung \enquote{Der PKW x ist eine Gefahrenquelle.} führen.

Enthält eine Ontologie Informationen über Fahrer, PKW und technische Daten über PKW-Modelle, so ist es beispielsweise möglich auf Basis der Daten aus Listing~\ref{lst:sample_rdf_data} zusätzliche Attribute der Fahrer wie \enquote{isDrivingCarModel} oder der PKW wie \enquote{hasEmergencyContactNumber} zu errechnen. Dieses funktioniert natürlich nur, falls in den Fakten bekannt ist, dass ein Fahrer ein Fahrzeug fährt und somit zu diesem Fahrzeug verbunden ist. Limitiert werden die Möglichkeiten des Reasoning ebenfalls durch die \emph{Open World Assumption} (OWA), also die Annahme einer offenen Welt, über die nur \emph{unvollständiges Wissen} vorliegt. Deshalb sollten für Reasoning nur explizit bekannte Fakten genutzt werden: Nur weil in Listing~\ref{lst:sample_rdf_data} keine Informationen über weitere PKW oder Fahrer vorhanden sind heißt das nicht, dass diese nicht existieren oder Einfluss auf die bekannten Fakten haben könnten.  Weiterführende Beispiele zu den Möglichkeiten von OWL Reasoning finden sich unter \cite{man:owl}.

Da Ontologien auch genutzt werden können, um Wissen aus den Strukturen einer Ontologie in die Struktur einer anderen Ontologie zu übersetzen, kann ein Reasoner die daraus resultierende Übersetzung direkt errechnen und der lokalen Datenbasis hinzufügen. Dadurch steht Abfragen, die schon auf die Ziel-Ontologie zugeschnitten sind, ein viel größerer Informationspool zur Verfügung, aus dem das Abfrageergebnis berechnet werden soll.

Diesen Vorteil erkauft man sich durch einen nicht unerheblichen Einsatz von Rechenleistung, da im Prozess des Reasoning eine Menge von zusätzlichen Daten entsteht, für die zusätzlich zu den bereits vorhandenen Daten die Regeln aller genutzten Ontologien berücksichtigt werden müssen. Behandelt man lediglich statische Daten, die sich kaum bis garnicht ändern, so ist der nötige Aufwand für Reasoning übersichtlich und liegt auch für große Mengen von Daten und Ontologien in einem akzeptablem Rahmen. Ändern sich jedoch häufig Daten, so muss für das Subset der veränderten Daten der Reasoning-Prozess erneut durchgeführt werden um eine vollständig aktuelle Datenbasis zu erhalten.


\section{Einführung in Complex Event Processing}\label{cpt:cep_intro}

\todo{Direkt mit RDF-Datenströmen anfangen, nächste Section mit dieser zusammenführen!}

\todo{Nun wollen wir auf Datenströmen im RDF-Format CEP fahren. Was genau bedeutet das eigentlich und wie sieht das in der Theorie aus?}
\todo{An Beispielszenario deutlich annähern, Konzept von CEP soll hier rein, allerdings noch nicht die Details}

\begin{itemize}
\item Definition von CEP
\item Ereignisse und Hintergrundwissen/Domänenwissen
\item Beispielhafter, fiktiver Ereignisstrom mit Hinweis auf Zeitachse
\item Kurzer Exkurs in Richtung Mustererkennung
\end{itemize}

Im folgenden Abschnitt wird ein kurzer Einstieg in das Konzept von Complex Event Processing (CEP) gegeben. Eine detailreiche Erläuterung von CEP und die beispielhafte Anwendung der CEP-Engine \enquote{Esper} wird in \cite{hsh:cep} beschrieben.

\todo{Diesen ganzen Abschnitt neu sortieren und analog zu der Einführung ins semantische Web aufbrechen und die einzelnen Begriffe in den Vordergrund rücken.}

Wie der Begriff \enquote{Complex Event Processing} schon andeutet, geht es bei CEP um die Verarbeitung von komplexen Ereignissen --- konkret: Die Erkennung und Erfassung von komplexen Ereignissen aus Datenströmen von primitiven Ereignissen. Von Messereignissen aus mit Sensoren ausgestatteten Geräten über Transaktionen im Handel bis hin zu Benutzerinteraktionen auf Webseiten entstehen täglich unzählig viele, primitive Ereignisse, die abhängig von ihrem Kontext für einen bestimmten Zeitraum ein Stück der echten Welt korrekt abbilden.

Die in diesen primitiven Ereignissen enthaltenen Informationen stellen nur einen momentanen Zustand dar; sie haben für sich alleine betrachtet keinen Kontext und somit vorerst bedeutungslos. Betrachtet man beispielsweise ein Ereignis \enquote{Die gemessene Temperatur beträgt 42°C.}, so ist zunächst nicht zu erkennen, was es mit dieser Temperatur auf sich hat. Hier kommt das für die Verarbeitung bereits bekannte \emph{Hintergrundwissen} (auch Domänenwissen) ins Spiel, welches das Ereignis in einen bekannten Kontext stellen kann. Es kann uns beispielsweise verraten, dass die Ereignisquelle ein Temperatursensor ist, der sich in einem PKW auf dem Motorblock befindet. Das Hintergrundwissen kann zu der bekannten Umgebung des Sensors viele weitere Angaben enthalten: Das konkrete Fabrikat des PKW, dessen Höchstgeschwindigkeit und die maximal zulässige Betriebstemperatur des Motors. Dieses Wissen ermöglicht schon eine genaue Einordnung der Informationen des Ereignisses; allerdings werden doch noch weitere Informationen benötigt, um ein eindeutiges Bild der Gesamtsituation zu erhalten. Kombiniert man das Temperaturereignis mit den Meldungen des im PKW installierten Geschwindigkeitssensors, so ergibt sich die Möglichkeit herauszufinden, ob für den aktuellen Betriebszustand des PKW die gemessene Motortemperatur.

Ein weiterer, wichtiger Faktor ist der Zeitraum in dem bestimmte Ereignisse auftreten. Um dies näher zu erläutern, betrachten wir den gegebenen Ereignisstrom aus Listing~\ref{lst:sample_eventstream}.
\begin{lstlisting}[caption={Exemplarischer Ereignisstrom: Motortemperatur eines PKW},label={lst:sample_eventstream}]
[Event #1] Temperatur: 40°C
[Event #2] Temperatur: 48°C
[Event #3] Temperatur: 61°C
[Event #4] Temperatur: 84°C
\end{lstlisting}
Auf den ersten Blick ist ersichtlich, dass die Messwerte einen sehr starken Temperaturanstieg abbilden, jedoch fehlt eine Angabe darüber, wie viel Zeit zwischen diesen Ereignissen vergangen ist. Dadurch ist die Interpretation dieser Ereignisse nicht mehr eindeutig möglich: Liegen zwischen den Messereignissen beispielsweise etwa 30-60 Minuten, so könnte es sich um einen normalen Betrieb bei hoher Geschwindigkeit handeln. Sollten jedoch nur wenige Minuten zwischen den Messereignissen vergangen sein, so lassen die Messwerte auf einen Defekt schließen und ein Motorschaden wäre eine mögliche Folge. Die Zeitachse darf somit bei der Ereignisverarbeitung nicht vernachlässigt werden.

Ein weiterer Kernaspekt von CEP ist die Mustererkennung in Ereignissen. Aus bestimmten primitiven Ereignissen, die in einer bestimmten Abfolge auftreten, soll ein konkreter Sachverhalt abgeleitet werden. Treten bei einem PKW beispielsweise in kurzer Zeit nacheinander die Ereignisse \enquote{Motor abgeschaltet}, \enquote{Fahrzeug verriegelt} und \enquote{PKW beschleunigt} auf, so könnte der Fall eingetreten sein, dass ein gerade abgestelltes Fahrzeug losgerollt ist und es sollte unverzüglich eine Reaktion darauf gestartet werden.

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.


\subsection{Ereignisse als RDF-Datenstrom}

\todo{Diese Sektion wird mit der obigen zusammengeführt und umstrukturiert. Da RDF zuvor eingeführt wurde, kann direkt damit eingeleitet werden, dass RDF-Datenströme ankommen.}

\todo{Begründung, warum Ereignisse hier über Event-Subjekte definiert werden sollten}

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}


\subsection{SPARQL-Erweiterung zur Verarbeitung von RDF-Datenströmen}

\todo{Grobes Konzept: CSPARQL als erweiterte Form von SPARQL für die Verwendung mit 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 PKWs zu einem komplexeren Beschleunigungsereignis kombiniert werden.

\begin{lstlisting}[caption={Generation von neuen Ereignissen aus existierenden 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 Listing ein wenig hervorheben, damit verbundene Schlüsselwörter hervorheben und Begriffe klären (Sliding Window, Timestamps, Range und Step, \dots}


\subsection{Reasoning auf RDF-Datenströmen?}

\todo{FALLS ich Reasoning rechtzeitig unterbringe, werde ich hier die Grundlagen von Reasoning auf Datenströmen und die zusätzlichen Herausforderungen dabei hier erklären. Der Prozess des Reasoning wurde auf statischen Daten bereits in der Einführung in das semantische Web erklärt.}

\begin{itemize}
\item Immer noch ein Forschungsgebiet
\item sehr hoher Datendurchsatz (viele kleine Ereignisse in geringem Zeitraum)
\item Ereignisinformationen ändern sich sehr häufig, sind nie sehr lange gültig und nicht immer relevant zur einer Abfrage
\item Aber: Ergebnisse sollen möglichst schnell vorliegen
\item $\Longrightarrow$ große Menge Rechenaufwand
\item Einer der möglichen Ansätze: Reasoner errechnet für die Ereignisse Tripel mit begrenzter Lebensdauer (z.B. in C-SPARQL-Engine verwendet) [Der Part wandert eventuell in das Konzept-Kapitel in dem ich erkläre, auf welche Weise ich das RDFS-Reasoning der Engine nutzen möchte.]
\end{itemize}


\chapter{Vergleich von CEP-Engines für RDF-Datenströme}\label{cpt:engine_comparison}
\todo{Zusammenfassungsüberleitung über das Kapitel}

Es gibt bereits einige Technologien um Ereignisströme zu verarbeiten.
Im Folgenden stelle ich nun ein paar bekannte CEP-Systeme kurz vor.

\todo{Am Ende des Kapitels werden die Engines kurz verglichen und anhand der tollen Argumente die Entscheidung für C-SPARQL begründet.}

Grobe Eckpunkte zur Orientierung:
\begin{itemize}
\item Woher kommt sie, wie sieht die Entwicklung zur Zeit aus?
\item Eckdaten über Implementierung
\item Fähigkeiten und Funktionen?
\end{itemize}


\section{EP-SPARQL}

\begin{itemize}
\item FZI Research Center for Information Technology (Karlsruhe, Deutschland)
\item Karlsruhe Institute of Technology (Karlsruhe, Deutschland)
\item Stony Brook University (New York, USA)
\item 2011? \cite{ep:unified}[Da kam zumindest diese Quelle raus]
\item \enquote{Event Processing SPARQL} \cite{ep:unified}
\item In Prolog implementierter Prototyp \cite{ep:unified}
\item Kann scheinbar Reasoning (nur RDFS, kein OWL?) \cite{ep:etalis}
\end{itemize}


\section{CQELS}

\begin{itemize}
\item Institut für Telekommunikationssysteme an der TU-Berlin (Berlin, Deutschland)
\item Insight Centre for Data Analytics an der National University of Ireland (Galway, Irland)
\item Institute of Information Systems an der Vienna University of Technology (Wien, Österreich)
\item 2015? \cite{cqels:stream}[Da kam zumindest diese Quelle raus]
\item \enquote{Continuous Query Evaluation over Linked Stream}
\item Soll sehr schnell sein\cite{cqels:stream}[Wurde in dieser Quelle behauptet]
\item Zugriff auf lokales RDF-Wissen via IRI möglich (also ganz klassisch)
\item CSPARQL auf RDF-Strömen
\item Feeder können CSV lesen und zu RDF-Strömen machen, die der Engine zugeführt werden
\item Listener können aus SPARQL-Query-Ergebnissen CSV produzieren
\item In Java implementiert
\item Kein Reasoning?
\item CQELS\footnote{Unter \url{http://graphofthings.org/debs2015/cqels.zip} ist ein VirtualBox-Image zum Ausprobieren von CQELS erhältlich.}
\end{itemize}


\section{C-SPARQL}

\begin{itemize}
\item Woher kommt sie, wie sieht die Entwicklung zur Zeit aus?
\item Eckdaten über Implementierung
\item Fähigkeiten und Funktionen?

\item Verarbeitet Ströme im RDF-Format. Kann Hintergrundwissen im RDF-Format einbeziehen. In Java implementiert und entsprechend auch recht einfach in Java-Projekte zu integrieren.
\item Timestamp-Funktionalität zur Zeit mit einem Bug versehen, aber generell immernoch nutzbar.
\item Integration von Hintergrundwissen und Abfragen über mehrere Streams kombiniert möglich.
\item Reasoning zur Zeit auf RDFS-Niveau enthalten, es gibt Papers zu den Themen
\end{itemize}


\section{Auswahl der Engine für die Arbeit}

\todo{Warum jetzt eigentlich C-SPARQL? Weil es in Java fährt, auf Jena basiert, Datenströme im RDF-Format direkt unterstützt, Generatoren zum Einspeisen in die Engine nutzt 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{Konzeption}

\todo{Zusammenfassungsüberleitung über das Kapitel}

\todo{Objektklassen und Attribute + deren Zusammenhänge [Für RDFS-Reasoning dann noch ein wenig mehr Details]}

\todo{FALLS es soweit kommt wird hier auch speziell hervorgehoben, mit welchen Konstrukten (Klassenhierarchien und Merkmale) das RDFS-Reasoning der Engine die Abfragen an einigen Stellen flexibler als gehabt ermöglicht.}

Um die Anforderungen der Autoverleihgesellschaft aus Kapitel~\ref{cpt:scenario} mit der in Kapitel~\ref{cpt:engine_comparison} ausgewählten CEP-Engine \enquote{C-SPARQL} zu implementieren, muss zunächst die Verarbeitung der Ereignisdaten geplant und vorbereitet werden. Da es zum Formulieren der CSPARQL-Abfragen nötig ist, die Struktur der Ereignisdaten, die Struktur des Domänenwissens und das dazugehörige Vokabular zu kennen, sollen diese Punkte für die Anforderungen des Beispielszenarios festgelegt werden. Im Anschluss daran sollen die CSPARQL-Anfragen für die Erfüllung der Anforderungen des Szenarios formuliert und erläutert werden.

\section{RDF-Ereignisströme}

\section{Ereignisstrom über PKW}




\section{Ereignisstrom über Kunden}


\section{Formulierung von CSPARQL-Abfragen}

\todo{Immer weiter treiben nach dem Schema Anforderung, abstrakte Condition-Action-Regel, konkrete CSPARQL-Regel}



\chapter{Implementierung mit der C-SPARQL Engine}

\todo{Zusammenfassungsüberleitung über das Kapitel}

\todo{In diesem Kapitel wird die Engine konkret ausgepackt und mit Java-Code benutzt. Es werden Datenstromgeneratoren gezeigt, Queries registriert und vielleicht etwas Reasoning eingeschaltet und dessen Ergebnisse begutachtet.}

In diesem Kapitel wird die C-SPARQL-Engine konkret vorgestellt und verwendet.
\begin{itemize}
\item RDF-Datenströme
\item Beispielszenario
\item Umsetzung mit C-SPARQL
\item Nötiger Code für das Grundsetup der Engine, Generatoren und co
\item Konkreter Blick auf die CSPARQL-Queries
\item Ergebnisse der Abfragen
\end{itemize}


\section{Nutzung der C-SPARQL Engine in Java}

\todo{TBD}
Im Folgenden wird auf die praktische Anwendung der C-SPARQL-Engine in einem Java-Projekt eingegangen. 

\begin{itemize}
\item Welche technischen Strukturen sieht die Engine vor,
\item wie werden Datenströme zugeführt,
\item wie werden Queries erzeugt, registriert und beobachtet,
\item was muss dabei beachtet werden, welche Fallstricke gibt es (zur Zeit)
\item wie wird Hintergrundwissen eingespeist und zur Laufzeit aktualisiert,
\item welche Schritte sind nötig um RDFS-Reasoning zu nutzen?
\item Und natürlich immer wieder mittendrin: Wie sehen die Ergebnisse aus, die dabei entstehen?
\end{itemize}

\todo{Die einzelnen Sections entstehen beim Schreiben der Texte.}


\section{Bewertung/Ergebnis}

\begin{itemize}
\item (Konnten die gestellten Anforderungen erfüllt werden?)
\item Was konnte erreicht werden?
\item Was konnte nicht erreicht werden?
\item Gab es Schwierigkeiten? [Guter Zeitpunkt, um hier f:timestamp() vs Tripel mit Literals zu erwähnen]
\item Wie hoch war der Aufwand?
\item Wie steht es um die Qualität der Ergebnisse?
\item Eventuell ein Blick auf die Performance?
\end{itemize}


\chapter{Fazit}

\todo{Zusammenfassungsüberleitung über das Kapitel}

\begin{itemize}
\item Bewertung der Ergebnisse im Abgleich mit den Anforderungen und dem Aufwand?
\item Ist es für die Anforderungen (und mehr) praxistauglich?
\item Oder gibt es zur Zeit bessere Alternativen?
\end{itemize}


\chapter{Ausblick}

\todo{Eventuell mit Fazit zusammenführen, wenn es nicht zu groß wird.}

\begin{itemize}
\item Kann man mit der Engine in Zukunft noch mehr schaffen?
\item Wie steht es um Reasoning? Geht das? Wenn ja, nur RDFS oder auch OWL? \todo{Ist der Unterschied zwischen den Beiden fürs erste sehr wichtig oder führt das zu weit?}
\end{itemize}

Vielleicht geht das mit dem Reasoning später ja noch besser --- aktueller Stand ist noch limitiert, aber es wird fleißig daran geforscht \dots



\chapter*{Dummy-Kapitel für Tests und Notizen}

\todo{Spätestens vor dem Druck muss dieses Kapitel raus aus dem Dokument.}

Fähigkeitenliste, die auf C-SPARQL-Engine zutrifft. Eventuell für den Vergleich von CEP-Engines hier mal gucken, was davon relevant und interessant ist.
\begin{itemize}
\item Verarbeitung von mehreren Ereignisströmen
\item Verknüpfung von Ereignissen
\item Konstruktion neuer Ereignisse
\item Sliding/Tumbling Windows
\item Mustererkennung (Abfolge, Präsenz/Absenz von Ereignissen [zeitlicher Abstand])
\item \enquote{COMPUTE EVERY} (Neuberechnung in festen Intervallen)
\item Ausführen von benutzerdefiniertem Code
\item Integration von Hintergrundwissen [aus weiteren Quellen]
\item Aggregationsfunktionen über mehrere Ereignisse (Sum, Avg, ...)
\item Vergleichsoperatoren für Selektionskriterien
\item Bonuspunkte: Reasoning (Logikoperationen und Schlussfolgerungen)
\end{itemize}

\textcolor{red}{Dieses Kapitel fliegt am Ende natürlich raus.}

Sil-ben ge-trenn-t mit ei-nem Strich

C--SPARQL (Zwei Striche ergeben einen Bindestrich)

Und dann --- neben vielen anderen Zeichen --- gibt es mit drei Strichen den Gedankenstrich.

Mit \enquote{enquote} wird Text in Anführungszeichen gesetzt, aber manchmal ist vielleicht der Einsatz von \texttt{texttt} sinnvoll. Im \textbf{Notfall} kann auch \textbf{textbf} genutzt werden. Dann gibt es noch \textit{textit}, \textsc{textsc}, \textsf{textsf} und \textsl{textsl}.

Quellenreferenzen
\begin{itemize}
\item \cite{hsh:cep}[Einstieg in CEP mit Beispielen aus Esper-Welt]
\item \cite{hsh:integrating}[Esper vs C-SPARQL CEP ohne Reasoning]
\item \cite{barbieri:reasoning}[Ansatz für Reasoning auf RDF-Strömen mit C-SPARQL]
\item \cite{barbieri:querying}[Grundlagen C-SPARQL für CEP]
\item \cite{cqels:stream}[CQELS-Paper]
\item \cite{ep:etalis}[ETALIS-Paper]
\item \cite{ep:unified}[EP-SPARQL-Paper]
\item \cite{man:owl}[Owl Reasoning Examples]
\item \cite{w3c:sparql}[W3C zu SPARQL]
\item \cite{iao:esper}[Marktübersicht Real-Time Monitoring Software]
\item \cite{w3c:turtle}[Die Turtle-Notation]
\item \cite{hitzler:semanticweb}[Grundlagen Semantic Web]
\end{itemize}


%%% Ende inhaltlicher Inhalt! %%%

% Literaturverzeichnis
% Schlüssel als Buchstaben
\bibliographystyle{alpha}
\bibliography{Literaturverweise}

\end{document}
% Nothing beyond this line!


% Referenz auf Bibtex mit Kommentar
% \cite{robbins:gawk}[Siehe ab S.95]

% Einbinden von Tex-Files
%\input{abkuerz.tex}
%\input{einfuehrung.tex}

% Einbinden von größeren Tex-Files, z.B. Kapiteln
%\include{normen}
%\include{aufbau}
%\include{zitieren}
%\include{form}
%\include{allgtips}
