[TASK] Generic commit

Bachelorarbeit.tex

@@ -176,11 +176,11 @@ Das Beispielszenario, welches für diese Arbeit verwendet wird, ist eine Autover
 \paragraph{Anforderungen}
 Um die Ziele der Autoverleihgesellschaft erreichen zu können, sollen folgende Situationen erkannt werden:
 \begin{itemize}
-\item Starker Verschleiß eines Fahrzeugs
-\item Auftretende Probleme am Fahrzeug, wie beispielsweise:
+\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 gemeldete Probleme
+\item Vom Fahrzeug selbst erkannte Probleme
 \end{itemize}
 \item Eintritt eines Unfalls
 \item Unbeabsichtigtes Wegrollen von abgestellten Fahrzeugen
@@ -189,7 +189,7 @@ Um die Ziele der Autoverleihgesellschaft erreichen zu können, sollen folgende S
 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 melden die einzelnen PKW kontinuierlich ihre Statuswerte:
+Über diesen Datenstrom sollen die einzelnen PKW kontinuierlich ihre Statuswerte melden:
 \begin{itemize}
 \item PKW verschlossen (ja/nein)
 \item Status des Motors (an/aus)
@@ -198,15 +198,15 @@ Um diese Situationen zu erkennen, sollen zwei RDF-Ereignisdatenströme zur spät
 \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, werden über diesen Datenstrom separat von den Statusdaten gemeldet.
+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 ein geliehenes PKW wieder zurück, so wird hierfür ein Ereignis in diesen Datenstrom eingespeist. Diese Ereignisse enthalten immer die eindeutige Kundennummer und die Nummer des geliehenen Fahrzeugs, um eine Zuordnung vornehmen zu können.
+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 baut die Zuordnung von Kunden zu den von ihnen geliehenen PKW auf, ordnet die einzelnen PKW bestimmten Automodellen zu und ermöglicht so eine konkrete Interpretation der von den PKW gemeldeten Daten.
+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 enthält in diesem Szenario folgende Informationen:
+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
@@ -218,25 +218,22 @@ Das Domänenwissen enthält in diesem Szenario folgende Informationen:
 	\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}
 
-\todo{Zusammenfassungsüberleitung über das Kapitel}
-
-Im vorherigen Kapitel wurde erklärt, weshalb CEP auf RDF-Datenströmen betrieben werden soll. Dieses Kapitel soll eine Einführung in diese beiden Begriffe bereitstellen.
+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 in das semantische Web}
+\section{Einführung: RDF im semantischen Web}
 
-\todo{Da wir CEP auf RDF-Datenströmen betreiben wollen kommt jetzt erst einmal eine Einführung in die bisher typische Welt von RDF, der dazugehörigen Abfragesprache SPARQL und ein kleiner Ausblick auf die Fähigkeiten von Reasoning auf statischen Daten.}
+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 wird 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.
+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}
@@ -285,9 +282,6 @@ car:0	carOnt:isDrivenBy	driver:0 .
 driver:0	carOnt:drives	car:0
 \end{lstlisting}
 
-\paragraph{Literale}
-\todo{Kommt noch - aber kurz erklären wäre sicher nicht verkehrt.}
-
 \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.
 
@@ -326,19 +320,25 @@ Bei der Modellierung von Wissen mit Hilfe von Beschreibungslogiken, zu denen auc
 
 \todo{An Beispielszenario annähern und erweitern}
 
-Die Abfrage von Wissen aus RDF-Daten erfolgt über die Abfragesprache 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.
+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 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. Im Folgenden zeigt Listing~\ref{lst:sample_sparql_query} eine einfache Abfrage auf den Daten aus Listing~\ref{lst:sample_rdf_data}.
+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#>
 
-\begin{lstlisting}[caption={Abfrage von \dots aus Daten von Listing~\ref{lst:sample_rdf_data}},label={lst:sample_sparql_query}]
-SELECT ...
+SELECT ?maxMotorRPM
 WHERE {
-	... TODO ...
+	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.
 
-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 --- speziell in der \texttt{WHERE}-Klausel --- zu finden: Hier 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 ein beliebiges Subjekt (gekennzeichnet durch \texttt{?marie}) gesucht, welches gleichzeitig vom Typ Person ist, den Namen \enquote{Marie} trägt und einen bisher unbekannten Bruder (\texttt{?brother}) hat, der einen noch unbekannten Namen (\texttt{?nameOfBrother}) trägt. Für jedes Subjekt, auf welches diese Beschreibung passt, ergibt sich nun ein Ergebnis, welches die in der \texttt{SELECT}-Klausel angegebenen Felder zurückgibt --- in diesem Fall also lediglich ein Ergebnis mit dem Wert \enquote{Max}.
+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 Erzeugung von Tripeln für Geschwister, die auf ihren jeweilige Schwester (\enquote{isSisterOf}) beziehungsweise ihren jeweiligen Bruder (\enquote{isBrotherOf}) zeigen.
 
 \begin{lstlisting}[caption={Konstruktion von Tripeln ...},label={lst:sample_sparql_construct}]
@@ -414,6 +414,8 @@ Insgesamt liegt die Herausforderung von CEP darin, in kürzester Zeit große Dat
 
 \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.
 
@@ -544,17 +546,21 @@ Grobe Eckpunkte zur Orientierung:
 
 \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 später nötig ist, die Struktur der Ereignisdaten, die Struktur des Domänenwissens und das dazugehörige Vokabular zu kennen, sollen diese für die Anforderungen des Beispielszenarios nun festgelegt werden. Im Anschluss daran sollen die CSPARQL-Anfragen für die Erfüllung der Anforderungen des Szenarios formuliert und erläutert werden.
+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}
+\todo{Immer weiter treiben nach dem Schema Anforderung, abstrakte Condition-Action-Regel, konkrete CSPARQL-Regel}