[TASK] Generic commit.
This commit is contained in:
parent
3c28d71e30
commit
a1377db4d0
@ -407,7 +407,7 @@ Dafür treten diese primitiven Ereignisse häufig mit einer sehr hohen Frequenz
|
||||
|
||||
Natürlich können nicht nur externe Komponenten als Quelle von Ereignissen dienen. Viele CEP-Engines unterstützen die Erzeugung von Ereignisdaten und deren Injektion in die eigene Ereignisverarbeitung. So können durch CEP-Regeln gewonnene Erkenntnisse direkt Einfluss auf die weitere Verarbeitung nehmen, indem sie als neue Ereignisse in die Verarbeitung aufgenommen werden.
|
||||
|
||||
\paragraph{CEP-Regeln} \todo{Ggf. nochmal weiter nach hinten schieben, macht ja nix.}
|
||||
\paragraph{CEP-Regeln}
|
||||
Zur Erläuterung von CEP-Regeln wird für diese hier eine aus Kapitel 3 von \cite{hsh:cep} entlehnte, abstrakte Sprache eingeführt, anhand derer die einzelnen Sprachkonstrukte von CEP-Regeln erläutert werden sollen.
|
||||
Eine CEP-Regel besteht zunächst aus zwei Teilen: Zuerst definiert der \texttt{CONDITION}-Teil Ereignismuster, die in dem Ereignisdatenstrom gesucht werden sollen, sowie spezifische Bedingungen, die für auf das Muster passende Ereignisse erfüllt sein müssen.
|
||||
\begin{lstlisting}[mathescape=true,label={},caption={}]
|
||||
@ -466,7 +466,7 @@ ACTION
|
||||
|
||||
\todo{GRAFIK: Mustererkennung grob veranschaulichen?}
|
||||
|
||||
\todo{Diesen Part eventuell weiter nach vorne schieben?}
|
||||
|
||||
\paragraph{Sliding Windows und Tumbling Windows}
|
||||
Um die großen Mengen von Ereignisdaten aus einem Datenstrom effizient verarbeiten zu können, werden sie in einem Fenster fester Größe betrachtet. Die Größe eines solchen Fensters wird häufig mit Zeiteinheiten wie Sekunden angegeben; selten wird die Größe durch eine Anzahl von Ereignissen angegeben, die das Fenster enthalten kann.
|
||||
|
||||
@ -647,7 +647,7 @@ Wie aus Listing~\ref{lst:sample_abstract_event_data} zu erkennen ist, ist jede E
|
||||
(1344829405) event:325 carOnt:relatedCar car:0 .
|
||||
(1344829405) event:325 carOnt:speed 75 .
|
||||
\end{lstlisting}
|
||||
Wie in Listing~\ref{lst:sample_event_rdf_quads} zu sehen ist, wurde die ID der Ereignisinstanzen zur Generierung der Subjekt-URI verwendet, die in den Quadrupeln verwendet werden, um die Ereignisse zu beschreiben. Aus dem Ereignistyp wurde eine Aussage, die die Subjekt-URI via \texttt{rdf:type} mit einer RDFS-Objektklasse verknüpft, die diesen Ereignistypen repräsentieren soll. Alle weiteren Attribute der Ereignisinstanzen wurden über eigens hierfür definierte RDFS-Prädikate dem Ereignissubjekt zugeordnet. Die Angabe des PKW, auf den sich die Ereignisinstanzen beziehen, wurde durch eine direkte Verknüpfung der Ereignissubjekte mit dem zugehörigen PKW-Subjekt modelliert. Die PKW-Subjekte sind hierbei im Domänenwissen hinterlegt; dazu später mehr\todo{Kapitelreferenz!}.
|
||||
Wie in Listing~\ref{lst:sample_event_rdf_quads} zu sehen ist, wurde die ID der Ereignisinstanzen zur Generierung der Subjekt-URI verwendet, die in den Quadrupeln verwendet werden, um die Ereignisse zu beschreiben. Aus dem Ereignistyp wurde eine Aussage, die die Subjekt-URI via \texttt{rdf:type} mit einer RDFS-Objektklasse verknüpft, die diesen Ereignistypen repräsentieren soll. Alle weiteren Attribute der Ereignisinstanzen wurden über eigens hierfür definierte RDFS-Prädikate dem Ereignissubjekt zugeordnet. Die Angabe des PKW, auf den sich die Ereignisinstanzen beziehen, wurde durch eine direkte Verknüpfung der Ereignissubjekte mit dem zugehörigen PKW-Subjekt modelliert. Die PKW-Subjekte sind hierbei im Domänenwissen hinterlegt; dazu später mehr in Kapitel~\ref{cpt:integrating_knowledge}.
|
||||
|
||||
|
||||
\section{C-SPARQL als Sprache für CEP-Regeln}
|
||||
@ -775,9 +775,7 @@ WHERE {
|
||||
Natürlich kann man diese Abfrage auch umkehren um alle Personentripel \textbf{mit} einer Namensangabe zu finden. Hierfür kommt anstelle von \texttt{FILTER NOT EXISTS \{ ... \}} nun \texttt{FILTER EXISTS \{ ... \}} zum Einsatz. Das Ergebnis der Abfrage wäre nun das Personentripel von \texttt{:alice}.
|
||||
\end{itemize}
|
||||
|
||||
\todo{Es folgt die Übersetzung der Operatoren der Ereignisalgebra aus Kapitel~\ref{cpt:cep_intro}, um zu erläutern, wie das alles in C-SPARQL funktionieren kann.}
|
||||
|
||||
Um nun in C-SPARQL Ereignismuster formulieren zu können, die denen aus Kapitel~\ref{cpt:cep_intro} entsprechen, müssen zunächst die Operatoren aus der Ereignisalgebra aus Anweisungen in C-SPARQL übersetzt werden.
|
||||
Um nun in C-SPARQL Ereignismuster formulieren zu können, die den Mustern aus Kapitel~\ref{cpt:cep_intro} entsprechen, müssen zunächst die Operatoren der Ereignisalgebra in die C-SPARQL-Sprache übersetzt werden.
|
||||
\begin{itemize}
|
||||
\item \textbf{Ereignistypen} $(A)$: Bevor die Operatoren aus der Ereignisalgebra verwendet werden können, muss zunächst die Selektion von Ereignissen spezifischer Typen gezeigt werden. Wie Listing~\ref{lst:sample_event_rdf_quads} bereits demonstriert hat, wird das Prädikat \texttt{rdf:type} verwendet, um den Ereignistyp einer Ereignisinstanz zu spezifizieren. Diese Angabe kann bei der Selektion von Tripeln verwendet werden, um nur Ereignisinstanzen eines bestimmten Ereignistypen zu erhalten. Platziert man das folgende Muster in der \texttt{WHERE}-Klausel einer C-SPARQL-Abfrage, so erhält man Subjekte von Ereignisinstanzen vom Typ \texttt{<http://example.org/type/A>} in der Variable \texttt{?eventA}:
|
||||
\begin{lstlisting}
|
||||
@ -932,7 +930,7 @@ WHERE {
|
||||
GROUP BY (?car)
|
||||
\end{lstlisting}
|
||||
|
||||
\section{Einbindung von Domänenwissen}
|
||||
\section{Einbindung von Domänenwissen}\label{cpt:integrating_knowledge}
|
||||
Zur Einbindung von lokalem Domänenwissen bietet C-SPARQL sehr leicht zugängliche Möglichkeiten. Bevor das lokale Domänenwissen in C-SPARQL-Queries zur Verfügung steht, muss es zunächst in einen Graphen geladen werden. Der folgende Code liest die in der Date \texttt{data/carSimulationABox.rdf} gespeicherten RDF-Daten und hinterlegt sie für die Engine in dem Graphen \texttt{http://example.org/carSimKnowledgeGraph}:
|
||||
\begin{lstlisting}
|
||||
engine.putStaticNamedModel("http://example.org/carSimKnowledgeGraph",
|
||||
@ -961,7 +959,7 @@ Die Verknüpfung von Ereignisdaten mit lokalem Domänenwissen ist bei der Nutzun
|
||||
|
||||
|
||||
\section{Reasoning auf RDF-Datenströmen}
|
||||
Die C-SPARQL-Engine unterstützt die automatische Anreicherung von RDF-Datenströmen und Abfrageergebnissen durch implizites Wissen, welches durch ein gegebenes RDFS-Vokabular abgeleitet werden konnte. Hierfür wird in der C-SPARQL-Engine die Implementierung des \texttt{GenericRuleReasoner} aus Apache Jena verwendet. Diesem Reasoner wird ein eigenes Regelwerk zugeführt, welches die Axiome und Folgerungsregeln von RDFS implementiert.
|
||||
Die C-SPARQL-Engine unterstützt die automatische Anreicherung von RDF-Da\-ten\-strö\-men und Abfrageergebnissen durch implizites Wissen, welches durch ein gegebenes RDFS-Vokabular abgeleitet werden konnte. Hierfür wird in der C-SPARQL-Engine die Implementierung des \texttt{GenericRuleReasoner} aus Apache Jena verwendet. Diesem Reasoner wird ein eigenes Regelwerk zugeführt, welches die Axiome und Folgerungsregeln von RDFS implementiert.
|
||||
|
||||
Um die Funktion zu aktivieren, müssen folgende Dinge berücksichtigt werden:
|
||||
\paragraph{Aktivierung der Inferenz}
|
||||
@ -978,7 +976,6 @@ Hat man auf diese Weise einen Query an der Engine registriert, so muss als näch
|
||||
\item \textbf{Hybrid}: Ein Ansatz, welcher Forward Chaining und Backward Chaining kombiniert.
|
||||
\end{itemize}
|
||||
|
||||
\todo{!}
|
||||
Die Details der technischen Implementierung von Reasoning in der C-SPARQL-Engine können in \cite{barbieri:reasoning} nachgelesen werden. Weiterführend kann über die Umsetzung von Reasoning mit Complex Event Processing in der Masterarbeit von Stefan Lier\cite{hsh:reasoning} gelesen werden.
|
||||
|
||||
\chapter{Umsetzung des Beispielszenarios}\label{cpt:csparql_in_practice}
|
||||
|
||||
Loading…
Reference in New Issue
Block a user