[TASK] Generic commit
This commit is contained in:
parent
71a1fa108c
commit
8fd02d7108
@ -188,10 +188,10 @@ 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 Autos}
|
||||
Über diesen Datenstrom melden die einzelnen Autos kontinuierlich ihre Statuswerte:
|
||||
\paragraph{Statusdatenstrom der PKW}
|
||||
Über diesen Datenstrom melden die einzelnen PKW kontinuierlich ihre Statuswerte:
|
||||
\begin{itemize}
|
||||
\item Auto verschlossen (ja/nein)
|
||||
\item PKW verschlossen (ja/nein)
|
||||
\item Status des Motors (an/aus)
|
||||
\item Status der Handbremse (angezogen/gelöst)
|
||||
\item Momentangeschwindigkeit in km/h
|
||||
@ -201,10 +201,10 @@ Um diese Situationen zu erkennen, sollen zwei RDF-Ereignisdatenströme zur spät
|
||||
Besonders wichtige Ereignisse, wie das Aufleuchten der Motorkontrollleuchte oder das Auslösen des Airbags, werden über diesen Datenstrom separat von den Statusdaten gemeldet.
|
||||
|
||||
\paragraph{Interaktionsstrom der Kunden}
|
||||
Wird einem Kunden ein Auto zugewiesen oder gibt ein Kunde ein geliehenes Auto 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 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.
|
||||
|
||||
\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 Autos auf, ordnet die einzelnen Autos bestimmten Automodellen zu und ermöglicht so eine konkrete Interpretation der von den Autos 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 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.
|
||||
|
||||
Das Domänenwissen enthält in diesem Szenario folgende Informationen:
|
||||
\begin{itemize}
|
||||
@ -258,7 +258,7 @@ car:23 carOnt:isCarModel carModel:42 .
|
||||
Ü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 Auto und dessen Modell},label={lst:sample_rdf_data}]
|
||||
\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#> .
|
||||
@ -430,7 +430,7 @@ http://example.org/cars/event#1468064960110 http://example.org/cars#currentSpeed
|
||||
\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 Autos zu einem komplexeren Beschleunigungsereignis kombiniert werden.
|
||||
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
|
||||
@ -540,18 +540,16 @@ Grobe Eckpunkte zur Orientierung:
|
||||
|
||||
\todo{Zusammenfassungsüberleitung über das Kapitel}
|
||||
|
||||
Um das Beispielszenario der Autoverleihgesellschaft aus Kapitel~\ref{cpt:scenario} mit der in Kapitel~\ref{cpt:engine_comparison} ausgewählten CEP-Engine \enquote{C-SPARQL} nun zu implementieren, muss zunächst die Verarbeitung der Ereignisdaten geplant und vorbereitet werden. Da es zum Formulieren von CSPARQL-Abfragen nötig ist, sowohl die Struktur der Ereignisdaten, die Struktur des Domänenwissens, und das in beiden verwendete Vokabular zu kennen, sollen diese für die Anforderungen des Beispielszenarios nun festgelegt werden. Im Anschluss daran sollen die eigentlichen CSPARQL-Anfragen formuliert und erläutert werden.
|
||||
|
||||
|
||||
\section{Anforderungen}
|
||||
|
||||
In Kapitel~\ref{cpt:scenario} wurden die Anforderungen des Beispielszenario aus Kapitel~\ref{cpt:scenario} bereits grob umrissen.
|
||||
|
||||
|
||||
\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 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.
|
||||
|
||||
\section{Ereignisstrom über PKW}
|
||||
|
||||
|
||||
\section{Ereignisstrom über Kunden}
|
||||
|
||||
|
||||
\section{Formulierung von CSPARQL-Abfragen}
|
||||
|
||||
Loading…
Reference in New Issue
Block a user