[TASK] Generic commit.

Bachelorarbeit.tex

@@ -307,6 +307,7 @@ carOnt:drives	rdfs:range	carOnt:Car .
 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}
+\todo{Mehr Inhalt! Das ist so zu wenig!}
 In OWL (Web Ontology Language) formulierte Ontologien werden im semantischen Web neben RDF-Schemata 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. Allerdings bietet OWL mächtigere Sprachkonstrukte, um feiner granulare Regeln für Objektklassen und Attribute aufzustellen. Eine Ontologie für Listing~\ref{lst:sample_rdf_data} könnte 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 auf inhaltlicher Ebene strukturiert werden.
 
 \paragraph{ABox und TBox}
@@ -324,14 +325,12 @@ Sollte es nötig sein, für eigene Terminologie eine Ontologie zu erzeugen, so i
 
 
 \subsection{Anreicherung von RDF-Daten durch Reasoning}\label{cpt:reasoning}
-\todo{OWL-Reasoning vs RDFS-Reasoning (Mächtigkeit)}
-
-\todo{Warum ist Reasoning hilfreich/wichtig/sinnvoll? - Automatische Anreicherung auf Basis der TBox}
-
 Durch den Einsatz von Terminologiewissen in Form von OWL-Ontologien oder RDF-Schemata ergibt sich die Möglichkeit, die Fakten aus der ABox automatisch um über die Terminologie abgeleitetes Wissen anzureichern. Diesen Prozess bezeichnet man als \emph{Reasoning}.
 
+\todo{Reasoning anhand von RDFS-TBox erklären: transitive und symmetrische Attribute sind leichter zu greifen!}
+
 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 verriegelt.} können zu der Folgerung \enquote{Der PKW x ist eine Gefahrenquelle.} führen.
-\todo{Andere Beispiele im Kontext statischer Daten?}
+\todo{Beispiel zu komplex, muss ersetzt werden!}
 
 Enthält eine Ontologie strukturelle Informationen über Fahrer, PKW und Attribute bezüglich technischer Daten über PKW-Modelle, so ist es beispielsweise möglich auf Basis der Fakten 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}.
 
@@ -405,12 +404,8 @@ Nur die Ereignisse, die in diesen Ereignisfenstern enthalten sind, werden somit
 
 \todo{GRAFIK: Sliding Window vs Tumbling Window} 
 
-\paragraph{Aggregation von Ereignissen}
-Eine einfache Möglichkeit um primitive Ereignisse auszuwerten ist die Aggregation von Ereignissen zu höherwertigeren Ereignissen. Hierbei werden alle Ereignisse gleichen Typs in einem Zeitfenster betrachtet und beispielsweise über eine Summen- oder Differenzbildung, einen Mittelwert oder durch simples Zählen aggregiert. Dadurch können erste Kennzahlen und Trends gewonnen werden, die dabei helfen können, die Entwicklung der Situation in diesem Zeitfenster besser nachzuvollziehen.
-
-\todo{GRAFIK: Aggregation grob zeigen?}
-
 \paragraph{Mustererkennung}
+\todo{Mehr! Mustererkennung!}
 Komplexere Sachverhalte kann man häufig über ihre Ereignismuster erkennen. Hierbei spielen die Ereignissequenzen und die zeitlichen Beziehungen zwischen Ereignissen eine Rolle. Um ein \enquote{bedeutungsvolles Ereignismuster} zu erkennen, wird eine CEP-Regel definiert, die dieses Muster beschreibt.
 Ein Beispiel für ein Ereignismuster, welches unsachgemäß abgestellte PKW erkennen kann, sieht so aus:
 \begin{itemize}
@@ -423,6 +418,11 @@ Man könnte nun eine CEP-Regel definieren, die für jeweils \emph{den selben} PK
 
 \todo{GRAFIK: Mustererkennung grob zeigen?}
 
+\paragraph{Aggregation von Ereignissen}
+Eine weitere Möglichkeit zur Auswertung primitiver Ereignisse ist die Aggregation von Ereignissen zu höherwertigeren Ereignissen. Hierbei werden alle Ereignisse gleichen Typs in einem Zeitfenster betrachtet und beispielsweise über eine Summen- oder Differenzbildung, einen Mittelwert oder durch simples Zählen aggregiert. Dadurch können erste Kennzahlen und Trends gewonnen werden, die dabei helfen können, die Entwicklung der Situation in diesem Zeitfenster besser nachzuvollziehen.
+
+\todo{GRAFIK: Aggregation grob zeigen?}
+
 \paragraph{Integration von Domänenwissen}
 Hat man in der Verarbeitung der Ereignisse durch CEP-Regeln alle Register gezogen, so kommt die Integration des Domänenwissens ins Spiel. Alle Fakten, die über die auszuwertenden Ereignisse bekannt sind, liegen hier vor. Beispiele dafür wären:
 \begin{itemize}
@@ -461,11 +461,13 @@ Ein \enquote{Hello World}-Softwarepaket zur Demonstration der Engine, welches un
 \section{Auswahl der Engine für die Arbeit}
 Da in dieser Arbeit die Verarbeitung von RDF-Ereignisdatenströmen anhand einer konkreten CEP-Engine erläutert werden soll, muss nun eine Entscheidung für eine CEP-Engine gefällt werden. Um einen möglichst einfachen Einstieg in die Thematik zu bekommen, soll die vorgestellte Engine möglichst wenig zusätzlichen Aufwand hervorrufen. Somit sind folgende Kriterien für die Auswahl der Engine verwendet worden:
 \begin{itemize}
-\item Workflow zur Verwendung der Engine klar strukturiert
-\item Verwendung wenig verschiedener Programmiersprachen
+\item Verwendung einer einzigen Programmiersprache
 \item Verwendung sehr verbreiteter Programmiersprachen
 \item Transparente Implementierung der Engine durch Verwendung bekannter Technologien
 \end{itemize}
+
+\todo{Tabelle o.Ä. zum direkten Vergleich der Kriterien!}
+
 Unter Berücksichtigung dieser Kriterien fiel die Wahl auf die CEP-Engine C-SPARQL; sie wird im weiteren Lauf der Arbeit vorgestellt, um die Verarbeitung von RDF-Er\-eig\-nis\-da\-ten\-strö\-men durchzuführen und das Beispielszenario aus Kapitel~\ref{cpt:scenario} umzusetzen.