[TASK] Generic commit
This commit is contained in:
parent
f0dff3cc2b
commit
a06d87181a
|
|
@ -205,13 +205,15 @@ Um die Ereignisdaten aus den beiden beschriebenen Datenströmen bei der Verarbei
|
|||
|
||||
\chapter{Grundlagen}\label{cpt:basics}
|
||||
|
||||
Bevor
|
||||
\todo{Zusammenfassungsüberleitung über das Kapitel}
|
||||
|
||||
|
||||
\section{Einführung in das semantische 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.}
|
||||
|
||||
|
||||
\subsection{RDF im semantischen Web}\label{cpt:rdf-semantic-web}
|
||||
|
||||
Das Ressource Description Framework (RDF) wird im semantischen Web zur Modellierung und Beschreibung 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. 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.
|
||||
|
|
@ -233,16 +235,13 @@ car:23 carOnt:isCarModel carModel:42 .
|
|||
|
||||
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 zwei Geschwister},label={lst:sample_rdf_data}]
|
||||
:personA rdf:type :person
|
||||
:personA :isGender :female
|
||||
:personA :hasName "Marie"
|
||||
\begin{lstlisting}[caption={RDF-Daten beschreiben ein Auto und einen Fahrer},label={lst:sample_rdf_data}]
|
||||
@prefix car: <http://example.org/carSim/objects/Car#> .
|
||||
@prefix carModel: <http://example.org/carSim/objects/CarModel#> .
|
||||
@prefix carOnt: <http://example.org/carSim/carSimulationOntology#> .
|
||||
|
||||
|
||||
:personB rdf:type :person
|
||||
:personB :isGender :male
|
||||
:personB :hasName "Max"
|
||||
|
||||
:personB :hasSibling :personA
|
||||
\end{lstlisting}
|
||||
|
||||
Da innerhalb des semantischen Web angestrebt wird, in RDF vorliegende Informationen gemeinsam zu nutzen, miteinander zu kombinieren und vernetzen zu können, werden RDF-Tripel meist als Quadrupel 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 somit 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 kombiniert werden können.
|
||||
|
|
@ -258,13 +257,10 @@ Die Abfrage von RDF-Daten erfolgt über die Sprache SPARQL (\enquote{SPARQL Prot
|
|||
|
||||
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}.
|
||||
|
||||
\begin{lstlisting}[caption={Abfrage des Namens des Bruders von Marie aus Daten von Listing~\ref{lst:sample_rdf_data}},label={lst:sample_sparql_query}]
|
||||
SELECT ?nameOfBrother
|
||||
\begin{lstlisting}[caption={Abfrage von \dots aus Daten von Listing~\ref{lst:sample_rdf_data}},label={lst:sample_sparql_query}]
|
||||
SELECT ...
|
||||
WHERE {
|
||||
?marie rdf:type :person .
|
||||
?marie :hasName "Marie" .
|
||||
?marie :hasSibling ?brother .
|
||||
?brother :hasName ?nameOfBrother .
|
||||
...
|
||||
}
|
||||
\end{lstlisting}
|
||||
|
||||
|
|
@ -272,15 +268,11 @@ Listing~\ref{lst:sample_sparql_query} zeigt, dass SPARQL in der groben Grundstru
|
|||
|
||||
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 über das Bruder/Schwester-Verhältnis von Personen},label={lst:sample_sparql_construct}]
|
||||
\begin{lstlisting}[caption={Konstruktion von Tripeln ...},label={lst:sample_sparql_construct}]
|
||||
CONSTRUCT {
|
||||
?sister :isSisterOf ?brother .
|
||||
?brother :isBrotherOf ?sister .
|
||||
...
|
||||
} WHERE {
|
||||
?sister rdf:type :person .
|
||||
?sister :isGender :female .
|
||||
?sister :hasSibling ?brother .
|
||||
?brother :isGender :male .
|
||||
...
|
||||
}
|
||||
\end{lstlisting}
|
||||
|
||||
|
|
@ -309,6 +301,8 @@ Diesen Vorteil erkauft man sich durch einen nicht unerheblichen Einsatz von Rech
|
|||
|
||||
\section{Einführung in Complex Event Processing}
|
||||
|
||||
\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?}
|
||||
|
||||
\begin{itemize}
|
||||
\item Definition von CEP
|
||||
\item Ereignisse und Hintergrundwissen/Domänenwissen
|
||||
|
|
@ -343,6 +337,8 @@ Insgesamt liegt die Herausforderung von CEP darin, in kürzester Zeit große Dat
|
|||
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?
|
||||
|
|
@ -353,7 +349,7 @@ Grobe Eckpunkte zur Orientierung:
|
|||
|
||||
\section*{Anforderungen an CEP-Engines}
|
||||
|
||||
\todo{Eventuell fliegt die Section raus; Es sind mehr Kriterien/Features als Anforderungen, mal sehen was damit geschehen wird}
|
||||
\todo{Die Section raus; Es sind mehr Kriterien/Features als Anforderungen, mal sehen was damit geschehen wird}
|
||||
|
||||
\begin{itemize}
|
||||
\item Verarbeitung von mehreren Ereignisströmen
|
||||
|
|
@ -415,11 +411,15 @@ Grobe Eckpunkte zur Orientierung:
|
|||
\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 und somit echt komfortabel in der Handhabung ist. Und trotzdem kommen noch akzeptable Ergebnisse mit minimalem Support für RDFS-Reasoning raus.}
|
||||
|
||||
\chapter{CEP auf RDF-Datenströmen (Konzept)}
|
||||
|
||||
\todo{Zusammenfassungsüberleitung über das Kapitel}
|
||||
|
||||
Hier kommt der Part hin mit der abstrakten CQL für die Situation + C-SPARQL-Queries
|
||||
\todo{In diesem Kapitel werden abstrakte Condition-Action-Regeln für das Beispielszenario formuliert und dann mit konkreten \enquote{C-SPARQL}-CSPARQL-Queries umgesetzt. }
|
||||
|
||||
|
||||
\section{Ereignisse als RDF-Datenstrom}
|
||||
|
|
@ -481,6 +481,7 @@ WHERE {
|
|||
|
||||
\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 und und und dann vielleicht etwas Reasoning eingeschaltet.}
|
||||
|
||||
In diesem Kapitel wird die C-SPARQL-Engine konkret vorgestellt und verwendet.
|
||||
\begin{itemize}
|
||||
|
|
|
|||
Loading…
Reference in New Issue