702 lines
56 KiB
TeX
702 lines
56 KiB
TeX
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
% Setup des Dokuments
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
\documentclass[12pt,DIV14,BCOR10mm,a4paper,twoside,parskip=half-,headsepline,headinclude]{scrreprt} % Grundgröße 12pt, zweiseitig
|
|
% Packages from template
|
|
\usepackage[headsepline,automark]{scrpage2} % Seitenköpfe automatisch
|
|
\KOMAoptions{headinclude} % Fix
|
|
\usepackage[german]{babel} % Sprachpaket für Deutsch (Umlaute, Trennung,deutsche Überschriften)
|
|
\usepackage{graphicx,hyperref} % Graphikeinbindung, Hyperref (alles klickbar, Bookmarks)
|
|
\usepackage{amssymb} % Math. Symbole aus AmsTeX
|
|
\usepackage[utf8]{inputenc} % Umlaute
|
|
% Custom packages
|
|
\usepackage[autostyle=true,german=quotes]{csquotes} % Anführungszeichen mit \enquote{}
|
|
\usepackage{textcomp} % Zusätzliches Package für °C
|
|
\usepackage{listings} % Codesnippets
|
|
\usepackage{scrhack} % Hack for lstlisting i suspect :-/
|
|
\usepackage{xcolor}
|
|
\usepackage{float}
|
|
\usepackage{soul}
|
|
\usepackage{verbatim} % für comment-environment
|
|
% Setup für Codeblocks
|
|
\lstset{
|
|
% Optionen
|
|
breaklines=true,
|
|
breakatwhitespace=true,
|
|
breakautoindent=true,
|
|
frame=single,
|
|
%framexleftmargin=19pt,
|
|
inputencoding=utf8,
|
|
%language=awk,
|
|
%numbers=left,
|
|
%numbersep=8pt,
|
|
showspaces=false,
|
|
showstringspaces=false,
|
|
tabsize=1,
|
|
%xleftmargin=19pt,
|
|
captionpos=b,
|
|
% Styling
|
|
basicstyle=\footnotesize\ttfamily,
|
|
commentstyle=\footnotesize,
|
|
keywordstyle=\footnotesize\ttfamily,
|
|
numberstyle=\footnotesize,
|
|
stringstyle=\footnotesize\ttfamily,
|
|
}
|
|
% Hack für Sonderzeichen in Codeblocks
|
|
\lstset{literate=%
|
|
{Ö}{{\"O}}1
|
|
{Ä}{{\"A}}1
|
|
{Ü}{{\"U}}1
|
|
{ß}{{\ss}}1
|
|
{ü}{{\"u}}1
|
|
{ä}{{\"a}}1
|
|
{ö}{{\"o}}1
|
|
{°}{{${^\circ}$}}1
|
|
}
|
|
|
|
% Befehl für TODO-Markierungen
|
|
\newcommand{\todo}[1]{\textcolor{blue}{\emph{TODO: #1}}}
|
|
|
|
% Befehl für Entwürfe und grobe Pläne
|
|
\newenvironment{draft}{\par\color{orange}\begin{center}Entwurf / Konzept\end{center}\hrule}{\hrule\par}
|
|
|
|
% Broken citation needs broken command
|
|
\newcommand\mathplus{+}
|
|
|
|
% Festlegung Kopf- und Fußzeile
|
|
\defpagestyle{meinstil}{%
|
|
{\headmark \hfill}
|
|
{\hfill \headmark}
|
|
{\hfill \headmark\hfill}
|
|
(\textwidth,.4pt)
|
|
}{%
|
|
(\textwidth,.4pt)
|
|
{\pagemark\hfill Jan Philipp Timme}
|
|
{Version 0.4 vom \today \hfill \pagemark}
|
|
{Version 0.4 vom \today \hfill \pagemark}
|
|
}
|
|
\pagestyle{meinstil}
|
|
|
|
\raggedbottom
|
|
|
|
\renewcommand{\topfraction}{1}
|
|
\renewcommand{\bottomfraction}{1}
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
% Beginn des Dokuments (Titelseite und der ganze Krempel)
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
\begin{document}
|
|
|
|
% Titelseite
|
|
\thispagestyle{empty}
|
|
\includegraphics[width=0.2\textwidth]{res/Wortmarke_WI_schwarz.pdf}
|
|
{ ~ \sffamily
|
|
\vfill
|
|
{\Huge\bfseries CEP auf RDF-Datenströmen (unter Integration von Hin\-ter\-grund\-wis\-sen) in der C-SPARQL-Engine}
|
|
\bigskip
|
|
|
|
{\Large Jan Philipp Timme
|
|
\\[2ex]
|
|
Bachelor-Arbeit im Studiengang "`Angewandte Informatik"'
|
|
\\[5ex]
|
|
\today
|
|
}
|
|
}
|
|
\vfill
|
|
~ \hfill
|
|
\includegraphics[height=0.3\paperheight]{res/H_WI_Pantone1665.pdf}
|
|
\vspace*{-3cm}
|
|
|
|
% Seite mit Personen und Selbstständigkeitserklärung
|
|
\newpage \thispagestyle{empty}
|
|
\begin{tabular}{ll}
|
|
{\bfseries\sffamily Autor} & Jan Philipp Timme \\
|
|
& Matrikelnummer 1271449 \\
|
|
& jan-philipp.timme@stud.hs-hannover.de \\[5ex]
|
|
{\bfseries\sffamily Erstprüfer} & Prof. Dr. Jürgen Dunkel \\
|
|
& Abteilung Informatik, Fakultät IV \\
|
|
& Hochschule Hannover \\
|
|
& juergen.dunkel@hs-hannover.de \\[5ex]
|
|
{\bfseries\sffamily Zweitprüfer} & Jeremias Dötterl, M. Sc. \\
|
|
& Abteilung Informatik, Fakultät IV \\
|
|
& Hochschule Hannover \\
|
|
& jeremias.doetterl@hs-hannover.de
|
|
\end{tabular}
|
|
|
|
\vfill
|
|
|
|
% fett und zentriert in der Minipage
|
|
\begin{center} \sffamily\bfseries Selbständigkeitserklärung \end{center}
|
|
|
|
Hiermit erkläre ich, dass ich die eingereichte Bachelor-Arbeit
|
|
selbständig und ohne fremde Hilfe verfasst, andere als die von mir angegebenen Quellen
|
|
und Hilfsmittel nicht benutzt und die den benutzten Werken wörtlich oder
|
|
inhaltlich entnommenen Stellen als solche kenntlich gemacht habe.
|
|
\vspace*{7ex}
|
|
|
|
Hannover, den \today \hfill Unterschrift
|
|
|
|
\pdfbookmark[0]{Inhalt}{contents}
|
|
% Inhaltsverzeichnis
|
|
\tableofcontents
|
|
% Abbildungsverzeichnis
|
|
\listoffigures
|
|
% Codeverzeichnis
|
|
\lstlistoflistings
|
|
% Tabellenverzeichnis
|
|
\listoftables
|
|
|
|
\newpage
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
%%% Hier geht es richtig los mit dem Text!
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
|
|
\chapter{Motivation}\label{cpt:motivation}
|
|
Mit der fortschreitenden Digitalisierung von Alltagsgegenständen und ihrer Verbindung mit dem Internet wächst das sogenannte Internet of Things. Dadurch sind auch immer mehr offene Systeme online verfügbar, die ihre Sensordaten und Zustandsinformationen als \emph{RDF}\footnote{Resource Description Framework --- Mehr dazu in Kapitel \ref{cpt:basics}}-Datenstrom anbieten. Diese Ereignisdatenströme liefern durchgehend und hochfrequent Ereignisdaten, sodass innerhalb kurzer Zeit sehr große Datenmengen anfallen, die zwecks Extraktion von Informationen und Auslösen von Reaktionen in kürzester Zeit verarbeitet werden sollen.
|
|
|
|
Die Ereignisdaten aus diesen Strömen bilden kleine Teile der Realität zumindest nä\-herungs\-wei\-se über die in ihnen enthalten Messdaten und Zustandsinformationen ab, sofern sie nicht bedingt durch technischen Defekt oder Messfehler ungültige Daten enthalten und somit vor der weiteren Verarbeitung herausgefiltert werden sollten. Ein weiteres Problem ist die stark begrenzte Gültigkeit von Ereignisdaten: Oft werden sie schon durch ein neu aufgetretenes Ereignis hinfällig und sind nicht mehr aktuell.
|
|
|
|
Ereignisse haben für sich alleine betrachtet neben einer begrenzten Gültigkeit eine begrenzte Aussagekraft, daher ist es zum höheren Verständnis der dahinter verborgenen Situation notwendig, sie mit zuvor aufgetretenen Ereignissen in einen Kontext zu setzen. Dadurch können mehrere kleine, hochfrequent auftretende Ereignisse zu einzelnen, niederfrequent auftretenden komplexen Ereignissen aggregiert werden und mittels Mustererkennung höherwertige Informationen aus den Ereignissen extrahiert werden. In Abbildung~\ref{fig:aggregation_patternmatching} wird die Aggregation von Ereignissen sowie die Mustererkennung exemplarisch dargestellt.
|
|
|
|
\begin{figure}[htbp]
|
|
\centering
|
|
\includegraphics[width=\textwidth]{img/aggregation-patternmatching.pdf}
|
|
\caption{Aggregation und Mustererkennung auf einem Ereignisstrom}
|
|
\label{fig:aggregation_patternmatching}
|
|
\end{figure}
|
|
|
|
Die Integration von \emph{Domänenwissen}\footnote{Hintergrundwissen für den Kontext der Ereignisverarbeitung, verändert sich während der Verarbeitung nur selten} ist ein weiterer Schritt, der die Brücke zwischen den aus komplexen Ereignissen gewonnenen Kenntnissen und bereits bekannten Fakten schlagen soll, um die gewonnenen Kenntnisse in einen eindeutigen Zusammenhang stellen und eine eindeutige Interpretation zu ermöglichen.
|
|
|
|
Um unter diesen Bedingungen viele Ereignisdatenströme mit hochfrequenten Ereignissen in nahezu Echtzeit zu verarbeiten ist \emph{CEP}\footnote{Complex-Event-Processing} das Mittel der Wahl: Mit CEP werden die Ereignisse der verschiedenen Datenströme für begrenzte Zeiträume im Speicher vorgehalten und innerhalb von sogenannten \emph{Sliding-Windows}\footnote{Mehr dazu in Kapitel~\ref{cpt:cep_intro}} betrachtet. Dabei können Ereignismuster erkannt werden und verschiedene Ereignisse aggregiert werden um neue komplexe Ereignisse zu erzeugen.
|
|
|
|
Ziel dieser Arbeit ist die Einführung in die Konzepte von CEP und RDF, sowie die Demonstration der praktischen Nutzung der CEP-Engine \enquote{C-SPARQL} zur Verarbeitung von RDF-Datenströmen am Beispiel einer Autoverleihgesellschaft zur Überwachung von Leihfahrzeugen. Auch soll ergründet werden, welche technischen Möglichkeiten existieren, um \emph{Reasoning} auf RDF-Datenströmen zu betreiben --- ein Prozess, durch den eine vorhandene Sammlung von Fakten auf Basis von vorgegebener Terminologie automatisch um daraus ableitbarem Wissen angereichert werden kann.
|
|
Diesbezüglich soll ergründet werden, welche CEP-Engines Reasoning bereits implementieren und wie weit ihre technischen Möglichkeiten reichen --- eine große Herausforderung, da die mit einzubeziehenden Ereignisdaten sich kontinuierlich verändern.
|
|
|
|
|
|
\section{Szenario}\label{cpt:scenario}
|
|
Das Beispielszenario, welches für diese Arbeit verwendet wird, ist eine Autoverleihgesellschaft, die ihren Fuhrpark überwachen möchte, um ihren Kunden vergünstigte Tarife für verschleißarmes Fahrverhalten anbieten zu können. Weiterhin soll auf plötzlich auftretende Probleme an den Leihwagen möglichst schnell reagiert werden können um Schäden zu begrenzen, gefährliche Situationen zu vermeiden und bei Bedarf dem Kunden unverzüglich einen Ersatzwagen oder weitere Serviceleistungen anbieten zu können.
|
|
|
|
\paragraph{Anforderungen}
|
|
Um die Ziele der Autoverleihgesellschaft erreichen zu können, sollen folgende Situationen erkannt werden:
|
|
\begin{itemize}
|
|
\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 erkannte Probleme
|
|
\end{itemize}
|
|
\item Eintritt eines Unfalls
|
|
\item Unbeabsichtigtes Wegrollen von abgestellten Fahrzeugen
|
|
\end{itemize}
|
|
|
|
Um diese Situationen zu erkennen, sollen zwei RDF-Ereignisdatenströme zur späteren Verarbeitung eingerichtet werden und eine Sammlung von Fakten in lokalem Do\-mä\-nen\-wis\-sen modelliert werden. Diese werden im Folgenden vorerst nur grob beschrieben.
|
|
|
|
\paragraph{Statusdatenstrom der PKW}
|
|
Über diesen Datenstrom sollen die einzelnen PKW kontinuierlich ihre Statuswerte melden:
|
|
\begin{itemize}
|
|
\item PKW verschlossen (ja/nein)
|
|
\item Status des Motors (an/aus)
|
|
\item Status der Handbremse (angezogen/gelöst)
|
|
\item Momentangeschwindigkeit in km/h
|
|
\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, sollen über diesen Datenstrom separat von den Statusdaten gemeldet werden.
|
|
|
|
\paragraph{Interaktionsstrom der Kunden}
|
|
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 ver\-füg\-ba\-res 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 soll in diesem Szenario folgende Informationen enthalten:
|
|
\begin{itemize}
|
|
\item Eindeutige Zuordnung von Kundennummer zu einem Kunden
|
|
\item Kundendaten wie Name und Telefonnummer
|
|
\item Eindeutige Zuordnung von Fahrzeugnummer zu Automodell
|
|
\item Wissen über Automodelle:
|
|
\begin{itemize}
|
|
\item Empfohlene Motordrehzahlbereiche für verschleißarmes Fahren
|
|
\item Vorgeschriebener Reifendruck
|
|
\end{itemize}
|
|
\end{itemize}
|
|
|
|
\todo{GRAFIK: Grobes Informationsnetzwerk zur Veranschaulichung der Zu\-sam\-men\-hän\-ge zwischen den drei Elementen (Ströme + Hintergrundwissen).}
|
|
|
|
|
|
\chapter{Grundlagen}\label{cpt:basics}
|
|
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: RDF im semantischen Web}
|
|
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 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}
|
|
|
|
Das in Listing~\ref{lst:sample_rdf_triple} enthaltene Tripel ordnet das Car-Subjekt \texttt{\#23} über das Prädikat \texttt{isCarModel} dem Objekt CarModell \texttt{\#42} zu.
|
|
|
|
\todo{GRAFIK: zwei Elipsen und ein Pfeil, alle mit je S/P/O beschriftet zur Verdeutlichung.}
|
|
|
|
\paragraph{Turtle-Notation mit Prefixen}
|
|
Wie anhand des Beispiels aus Listing~\ref{lst:sample_rdf_triple} erkennbar ist, ist die explizite Notation für Tripel aufgrund der häufigen Nennung von vollständigen URIs wenig platzsparend und für große Datenmengen somit nicht empfehlenswert. Da es neben XML noch andere Repräsentationsformate für RDF-Daten gibt, bietet sich die Nutzung einer Notation an, die eine Nutzung von Prefixen erlaubt. Nach einer einmaligen Definition innerhalb eines Kontextes (zum Beispiel einer Datei) können diese Prefixe dann für den gesamten Kontext verwendet werden und verringern somit erheblich den Bedarf an Speicherplatz.
|
|
Listing~\ref{lst:sample_rdf_triple_with_prefix} zeigt die Notation von Tripeln im Turtle\footnote{Siehe auch die Spezifikation der Turtle-Notation nach \cite{w3c:turtle}}-Format unter Verwendung von Prefixen.
|
|
\begin{lstlisting}[caption={Das Tripel aus Listing~\ref{lst:sample_rdf_triple} mit Prefixen},label={lst:sample_rdf_triple_with_prefix}]
|
|
@prefix car: <http://example.org/carSim/objects/Car#> .
|
|
@prefix carModel: <http://example.org/carSim/objects/CarModel#> .
|
|
@prefix carOnt: <http://example.org/carSim/carSimulationOntology#> .
|
|
|
|
car:23 carOnt:isCarModel carModel:42 .
|
|
\end{lstlisting}
|
|
|
|
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 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#> .
|
|
@prefix carModel: <http://example.org/carSim/objects/CarModel#> .
|
|
@prefix driver: <http://example.org/carSim/objects/Driver#> .
|
|
@prefix carOnt: <http://example.org/carSim/carSimulationOntology#> .
|
|
|
|
car:0 rdf:type carOnt:Car .
|
|
car:0 carOnt:isCarModel carModel:0 .
|
|
|
|
carModel:0 rdf:type carOnt:CarModel .
|
|
carModel:0 carOnt:minimumMotorRPM 2000 .
|
|
carModel:0 carOnt:maximumMotorRPM 4300 .
|
|
carModel:0 carOnt:minimumTirePressure 2.9 .
|
|
carModel:0 carOnt:maximumTirePressure 3.2 .
|
|
carModel:0 carOnt:requiresDriverLicense "B"^^xsd:string
|
|
|
|
driver:0 rdf:type carOnt:Driver .
|
|
driver:0 carOnt:hasName "Max Mustermann"^^xsd:string .
|
|
driver:0 carOnt:hasPhoneNumber "+49 111 123456789"^^xsd:string .
|
|
driver:0 carOnt:hasDriverLicense "B"^^xsd:string .
|
|
|
|
car:0 carOnt:isDrivenBy driver:0 .
|
|
driver:0 carOnt:drives car:0
|
|
\end{lstlisting}
|
|
|
|
\paragraph{Objektklassen und -instanzen}
|
|
In RDF kann ein Subjekt grundsätzlich eine Instanz von mehreren Objektklassen sein. Um anzugeben, von welcher Objektklasse ein Tripel-Subjekt eine Instanz ist, wird das Prädikat \texttt{rdf:type} verwendet. Synonym dazu kann anstelle von \texttt{rdf:type} auch das Prädikat \texttt{a} verwendet werden, wie Listing~\ref{lst:sample_rdf_a_predicate} zeigt.
|
|
\begin{lstlisting}[caption={Das Prädikat \texttt{a} ist synonym zu \texttt{rdf:type}},label={lst:sample_rdf_a_predicate}]
|
|
@prefix car: <http://example.org/carSim/objects/Car#> .
|
|
@prefix carOnt: <http://example.org/carSim/carSimulationOntology#> .
|
|
|
|
car:0 a carOnt:Car .
|
|
\end{lstlisting}
|
|
Abhängig von den Objektklassen eines Subjektes können Ontologien nun einschränken, wie eine Objektinstanz mit anderen Objektinstanzen oder Werten verbunden werden darf. So kann beispielsweise definiert werden, dass das Prädikat \texttt{carOnt:drives} als Subjekt nur Instanzen der Klasse \texttt{carOnt:Driver} und als Objekt nur Instanzen der Klasse \texttt{carOnt:Car} zulässt, da die umgekehrte Richtung nicht sinnvoll wäre.
|
|
|
|
\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.
|
|
|
|
\todo{GRAFIK: Verbildlichung durch mehrere mit URI gekennzeichneten Container, die ein paar Tripel enthalten, die aufeinander verweisen.}
|
|
|
|
\paragraph{RDF-Schema für einfache Ontologien}
|
|
Das \enquote{RDF-Schema} (kurz RDFS\footnote{Für eine detailreiche Einführung in RDFS siehe auch \cite{hitzler:semanticweb}[Kapitel 3.4]}) dient zur Spezifikation von Schemawissen durch die Definition von Objektklassen und Prädikaten, welche in hierarchischen Verhältnissen zueinander stehen können\footnote{Mittels \texttt{rdfs:subclassOf} und \texttt{rdfs:subpropertyOf} können hierarchische Verhältnisse zwischen verschiedene Properties beziehungsweise Objektklassen definiert werden.}. Betrachtet man beispielsweise die Daten aus Listing~\ref{lst:sample_rdf_data}, so ist in diesem Kontext für die Verwendung des Prädikats \texttt{carOnt:drives} offensichtlich, dass es nur zusammen mit einem Subjekt der Klasse \texttt{Driver} und einem Objekt der Klasse \texttt{Car} verwendet werden sollte um eine sinnvolle Aussage zu ergeben. Eine solche Regel kann mit Hilfe von RDFS definiert werden, wie Listing~\ref{lst:sample_rdfs_data} zeigt.
|
|
\begin{lstlisting}[caption={Definition der Klassen \texttt{Car} und \texttt{Driver} sowie des Prädikats \texttt{drives} in RDFS},label={lst:sample_rdfs_data}]
|
|
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
|
|
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
|
|
@prefix carOnt: <http://example.org/carSim/carSimulationOntology#> .
|
|
|
|
carOnt:Car rdf:type rdfs:class .
|
|
carOnt:Driver rdf:type rdfs:class .
|
|
|
|
carOnt:drives rdf:type rdf:Property .
|
|
carOnt:drives rdfs:domain carOnt:Driver .
|
|
carOnt:drives rdfs:range carOnt:Car .
|
|
\end{lstlisting}
|
|
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}
|
|
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 viel mehr Werkzeuge 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}
|
|
Bei der Modellierung von Wissen mit Hilfe von Beschreibungslogiken, zu denen auch OWL und RDFS zählen, werden die formulierten Aussagen in zwei Gruppen unterteilt\cite{hitzler:semanticweb}[Kapitel 6.1]: Die Assertion Box (ABox) und die Terminology Box (TBox). Während die TBox Aussagen mit terminologischem Schemawissen wie Definitionen von Objektklassen, Prädikaten und ihren Verhältnissen zueinander enthält, beinhaltet die ABox sogenanntes \emph{assertionales Instanzwissen}\cite{hitzler:semanticweb}[Kapitel 6.1], welches aus Aussagen über konkrete Klasseninstanzen und deren Merkmale und Beziehungen besteht. In diesen Aussagen der ABox wird dabei das in der TBox definierte Vokabular genutzt.
|
|
|
|
Ein Beispiel für eine TBox ist Listing~\ref{lst:sample_rdfs_data}, in welcher Objektklassen definiert werden, die innerhalb der ABox aus Listing~\ref{lst:sample_rdf_data} verwendet werden, um konkrete Instanzen dieser Objektklassen zu beschreiben.
|
|
|
|
\todo{GRAFIK: Ein wenig visualisiertes Wissen, welches TBox und ABox-Inhalte getrennt voneinander darstellt. (Eine Ebene mit Klassen und Attributen, eine andere Ebene mit konkreten Klasseninstanzen und deren Merkmalen)}
|
|
|
|
\paragraph{Kombination verschiedener Ontologien}
|
|
Natürlich ist es möglich, mehrere verschiedene Ontologien gleichzeitig zu verwenden. Diese Flexibilität ermöglicht beispielsweise, dass eine bereits in RDF abgebildete Person durch beliebige Informationen über Vokabular aus weiteren Ontologien ergänzt werden kann. Natürlich können die Informationen einer in RDF abgebildeten Person auch in verschiedenen, für andere Parteien geläufigen Strukturen verfügbar gemacht werden können. Innerhalb einer Ontologie auf die Objektklassen und Attribute zurückgegriffen werden, die in anderen Ontologien definiert werden. Dies ermöglicht neben Erweiterungen für spezifische Zwecke auch das Übersetzen von Wissen zwischen verschiedenen Ontologien durch die Definition von äquivalenten Objektklassen und Attributen.
|
|
|
|
\paragraph{Open World Assumption}
|
|
Sollte es nötig sein, für eigene Terminologie eine Ontologie zu erzeugen, so ist es wichtig hervorzuheben, dass für in RDF abgebildete Fakten nahezu immer die Annahme gilt, dass diese Daten nicht vollständig sind und somit nicht alle realen Fakten auch in RDF erfasst sind. Die meisten existierenden Ontologien respektieren diese Annahme und verzichten auf die Definition von expliziten Regeln, die über die konkrete Bedeutung der Abwesenheit von bestimmten Fakten entscheiden würden. (In der Welt der relationalen Datenbanksysteme gibt es eine ähnliche Problematik in Zusammenhang mit der Verwendung des Schlüsselworts \texttt{NULL}.)
|
|
|
|
|
|
\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}.
|
|
|
|
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?}
|
|
|
|
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}.
|
|
|
|
Da Ontologien auch genutzt werden können, um Wissen aus den Strukturen einer Ontologie in die Struktur einer anderen Ontologie zu übersetzen, kann ein Reasoner die daraus resultierende Übersetzung direkt errechnen und der lokalen Datenbasis hinzufügen. Dadurch steht Abfragen, die schon auf die Ziel-Ontologie zugeschnitten sind, ein viel größerer Informationspool zur Verfügung, aus dem das Abfrageergebnis berechnet werden soll.
|
|
|
|
Die Vorteile von Reasoning erkauft man sich durch einen nicht unerheblichen Einsatz von Rechenleistung, da im Prozess des Reasoning eine Menge von zusätzlichen Daten entsteht, für die zusätzlich zu den bereits vorhandenen Daten die Regeln aller genutzten Ontologien berücksichtigt werden müssen. Behandelt man lediglich statische Daten, die sich kaum bis garnicht ändern, so ist der nötige Aufwand für Reasoning übersichtlich und liegt auch für große Mengen von Daten und Ontologien in einem akzeptablem Rahmen. Ändern sich jedoch häufig Daten, so muss für das Subset der veränderten Daten der Reasoning-Prozess erneut durchgeführt werden um eine vollständig aktuelle Datenbasis zu erhalten.
|
|
|
|
|
|
\subsection{Abfrage von RDF-Daten via SPARQL}\label{cpt:rdf-sparql}
|
|
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\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#>
|
|
|
|
SELECT ?maxMotorRPM
|
|
WHERE {
|
|
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.
|
|
|
|
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 den Befehl \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 beispielhafte Erzeugung von Tripeln auf Basis der Daten aus Listing~\ref{lst:sample_rdf_data}, welche über das Prädikat \texttt{carOnt:motorRPMTolerance} Auskunft über die Größe des akzeptablen Drehzahlbereiches der Automodelle geben sollen.
|
|
\begin{lstlisting}[caption={Konstruktion von neuen Tripeln auf Basis des Wissens aus Listing~\ref{lst:sample_rdf_data}},label={lst:sample_sparql_construct}]
|
|
PREFIX carOnt: <http://example.org/carSim/carSimulationOntology#>
|
|
PREFIX car: <http://example.org/carSim/objects/Car#>
|
|
|
|
CONSTRUCT {
|
|
?carModel carOnt:motorRPMTolerance ?rpmTolerance .
|
|
} WHERE {
|
|
?carModel rdf:type carOnt:CarModel .
|
|
?carModel carOnt:minimumMotorRPM ?minMotorRPM .
|
|
?carModel carOnt:maximumMotorRPM ?maxMotorRPM .
|
|
BIND(?maxMotorRPM - ?minMotorRPM AS ?rpmTolerance) .
|
|
}
|
|
\end{lstlisting}
|
|
Wie in Listing~\ref{lst:sample_sparql_construct} gezeigt, können einfache Operationen in SPARQL-Abfragen durchgeführt werden, deren Ergebnisse über die \texttt{BIND}-Anweisung in einen vorgegebenen Platzhalter \texttt{?rpmTolerance} eingesetzt werden. In diesem Beispiel wurde die Differenz zwischen der maximalen und der minimalen empfohlenen Motordrehzahl eines Automodells ausgerechnet und ein neues Tripel mit dieser Information generiert.
|
|
|
|
|
|
\section{Einführung in Complex Event Processing}\label{cpt:cep_intro}
|
|
Von Transaktionen im Handel über Messereignisse von Sensoren bis hin zu Benutzerinteraktionen auf Webseiten entstehen täglich eine Vielzahl von Ereignisdaten, die für einen begrenzten Zeitraum einen Teil der echten Welt abbilden. Um aus diesen großen Datenmengen durch Erkennung von Mustern oder durch Aggregation von Daten schnellstmöglich höherwertige Informationen gewinnen zu können, ist Complex Event Processing (CEP) das Mittel der Wahl. Wie der Begriff CEP bereits andeutet, geht es dabei um die Verarbeitung von komplexen Ereignissen. Im folgenden Abschnitt wird hierfür ein kurzer Einstieg in die Grundlagen von CEP gegeben. Für eine detailreiche Erläuterung und die beispielhafte Anwendung der CEP-Engine \enquote{Esper} sei auf \cite{hsh:cep} verwiesen.
|
|
|
|
\paragraph{CEP-Engine}
|
|
Um Complex Event Processing durchführen zu können, wird eine CEP-Engine benötigt. Eine CEP-Engine ist eine Software, welche Ereignisdatenströme konsumiert und durch die Auswertung benutzerdefinierter CEP-Regeln verarbeitet. Aufgrund der großen Datenvolumen, die eine CEP-Engine verarbeiten muss, werden Ereignisse nur für die Dauer der Verarbeitung im Speicher gehalten\footnote{Dieser Parameter hängt meist von der Größe der verwendeten Sliding Windows ab.} und nicht persistiert.
|
|
|
|
\paragraph{CEP-Regeln}
|
|
Eine CEP Regel definiert Bedingungen, die in einem Ereignisdatenstrom gesucht werden sollen, gefolgt von Aktionen, die bei zutreffenden Bedingungen ausgeführt werden sollen. Passen Ereignisse aus dem Datenstrom auf die Bedingungen, so matcht die Regel. Die in der Regel definierten Aktionen werden dann ausgeführt --- die Regel feuert.
|
|
|
|
\paragraph{Ereignisse}
|
|
Ein Ereignis trägt neben inhaltlichen Informationen über den Vorgang durch den es ausgelöst wurde auch eine eindeutige ID sowie einen Zeitstempel mit sich. Während der Zeitstempel den Zeitpunkt der Ereignisauslösung angibt, dient die ID zur eindeutigen Abgrenzung von anderen Ereignisssen, die vom selben Typ sind oder zum selben Zeitpunkt entstanden sind. Da es bedingt durch Übertragunglatenz und weitere technische Randbedingungen möglich ist, dass die Ereignisdaten zeitverzögert bei der CEP-Engine ankommen, wird der Zeitstempel ebenfalls benötigt, um die zeitlichen Beziehungen zwischen den Ereignissen zu erhalten.
|
|
|
|
Jedes Ereignis trägt eine geringe Menge von Daten mit sich, die für das Ereignis spezifische Informationen enthalten. Dies können beispielsweise Daten von Sensoren, Angaben über eine Benutzersitzung oder Statusdaten eines Systems sein. Diese Daten sind jedoch nur \emph{Momentaufnahmen} und verlieren mit fortschreitender Zeit meist an Gültigkeit.
|
|
|
|
Dafür treten diese primitiven Ereignisse häufig mit einer sehr hohen Frequenz auf, da ein Vorgang bei seiner Durchführung eine Vielzahl von Ereignissen auslösen kann. Betrachtet man beispielsweise einen aus dem Stand anfahrenden PKW bis zu seiner Erreichung von 30km/h, so würde man zusätzlich zu periodisch gemeldeten Messwerten aus dem Motorraum und Informationen über Gangwechsel des Getriebes eine Flut von Informationen darüber erhalten, wie die Pedale durch den Fahrer bedient wurden oder wie das Lenkrades eingeschlagen wurde.
|
|
|
|
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{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 in Sekunden angegeben; sehr selten wird die Größe durch eine maximale Anzahl von Ereignissen angegeben, die das Fenster enthalten kann.
|
|
|
|
Ein \emph{Sliding Window} wird in regelmäßigen Intervallen um eine festgelegten Größe verschoben, um aktuellere Ereignisse zu betrachten, wobei die älteren Ereignisse zugunsten der neuen Ereignisse aus dem Fenster herausfallen. Ein \emph{Tumbling Window} hingegen wird nicht verschoben sondern \enquote{umgeklappt}, sodass alle zuvor in ihm enthaltenen Ereignisse herausfallen und aktuellere Ereignisse in das nun leere Fenster gefüttert werden.
|
|
|
|
\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}
|
|
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}
|
|
\item Ereignis: Motor wurde abgeschaltet
|
|
\item \st{Ereignis: Handbremse wurde angezogen} (\textbf{nicht} passiert!)
|
|
\item Ereignis: PKW wurde verriegelt
|
|
\end{itemize}
|
|
|
|
Man könnte nun eine CEP-Regel definieren, die für jeweils \emph{den selben} PKW nach den Ereignissen \enquote{Motor wurde abgeschaltet} und \enquote{PKW wurde verriegelt} sucht und zwischen diesen Ereignissen kein Ereignis \enquote{Handbremse wurde angezogen} erwartet. Matcht diese Regel, so könnte man darauf basierend ein neues Ereignis erzeugen, welches auf diesen Umstand hinweist --- oder direkt einen Alarm auslösen und beispielsweise den Fahrer benachrichtigen.
|
|
|
|
\todo{GRAFIK: Mustererkennung 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}
|
|
\item Wo ein Sensor positioniert ist und was er misst
|
|
\item Von welchem Modell ein zu überwachendes Fahrzeug ist und welche bekannten Grenzwerte für den Betrieb eingehalten werden müssen
|
|
\item Wer ein überwachtes Fahrzeug gerade verwendet
|
|
\end{itemize}
|
|
Das Domänenwissen kann somit verwendet werden, um einer durch Ereignisdaten beschriebenen Situation einen eindeutigen Kontext zuzuordnen und somit die Interpretation der Daten stark zu erleichtern. Hat die Ereignisverarbeitung beispielsweise festgestellt, dass die durchschnittliche Drehzahl eines Motors bei 4200 Umdrehungen pro Minute liegt, so kann über das Domänenwissen nachgeschlagen werden, in welchem Fahrzeug der betroffene Motor montiert ist, von welchem Typen das Fahrzeug ist, und ob die Motordrehzahl für diesen Fahrzeugtypen zulässig ist.
|
|
|
|
Insgesamt liegt die Herausforderung von CEP darin, in kürzester Zeit große Datenströme von Ereignissen mit Hintergrundwissen anzureichern, diese zu höherwertigen Ereignissen zu kombinieren und bestimmte Muster zu finden, sowie die Ergebnisse mit möglichst geringer Verzögerung in Echtzeit ausgeben zu können oder Reaktionen einzuleiten.
|
|
|
|
|
|
\chapter{Vergleich aktueller RDF-fähiger CEP-Engines}\label{cpt:engine_comparison}
|
|
Nachdem ein kurzer Einstieg in die Welt von RDF und CEP gegeben wurde, soll nun eine CEP-Engine ausgewählt werden, mit der RDF-Ereignisdatenströme verarbeitet werden können, um das Beispielszenario aus Kapitel~\ref{cpt:scenario} im weiteren Verlauf der Arbeit umsetzen zu können. In diesem Kapitel werden drei CEP-Engines vorgestellt, die einen CSPARQL-Dialekt implementieren --- eine Form der Abfagesprache SPARQL, welche um Sprachkonstrukte erweitert wurde, die speziell auf die Verarbeitung von RDF-Datenströmen zugeschnitten sind. Eine der Engines soll in diesem Kapitel zur Umsetzung des Beispielszenarios aus Kapitel~\ref{cpt:scenario} ausgewählt werden.
|
|
|
|
\section{EP-SPARQL mit der ETALIS-Engine}
|
|
Die ETALIS-Engine stellt zur Formulierung von CEP-Regeln neben der eigenen Sprache ELE (\enquote{Etalis Language for Events}) die Sprache EP-SPARQL (\enquote{Event Processing SPARQL}) zur Verfügung\cite{ep:etalis}. Ein erstes Paper\cite{ep:etalis} über die Engine erschien 2009; die Autoren lassen darauf schließen, dass die Engine vom FZI Forschungszentrum Informatik (Karlsruhe, Deutschland), dem Karlsruher Institut für Technologie (Karlsruhe, Deutschland), und der Stony Brook University (New York, USA) entwickelt wurde.
|
|
|
|
Bei der Engine handelt es sich um einen in Prolog implementierten Prototyp\cite{ep:unified}, der neben der Integration von lokalem Domänenwissen auch Reasoning auf Basis von gegebenem RDFS-Vokabular auf den Ereignisdaten unterstützt\cite{ep:etalis}. Dabei werden Fakten und CEP-Regeln direkt übersetzt um die vorhandene Prolog-Umgebung zur Auswertung nutzen zu können\cite{hsh:integrating}. Neben einer Schnittstelle für die Sprache Prolog stehen auch Schnittstellen für Java, C und C\# zur Verfügung\cite{ep:etalis}, jedoch wird für den Betrieb der Engine zusätzlich immer eine Prolog-Laufzeitumgebung benötigt.
|
|
|
|
|
|
\section{Das CQELS-Framework}
|
|
Das CQELS-Framework (Continuous Query Evaluation over Linked Stream) wurde in Zusammenarbeit von dem Insight Centre for Data Analytics an der National University of Ireland (Galway, Irland), dem Institute of Information Systems an der Vienna University of Technology (Wien, Österreich) und dem Institut für Telekommunikationssysteme an der TU-Berlin (Berlin, Deutschland) entwickelt; ein erstes Paper über CQELS erschien 2011\cite{cqels:native}. Es wurde in Java implementiert und unterstützt die Einbindung von lokalem Domänenwissen in die Ereignisverarbeitung\cite{cqels:stream}. Über Reasoning-Fähigkeiten konnten bisher keine Angaben gefunden werden, jedoch kann nicht ausgeschlossen werden, dass Reasoning mit CQELS möglich ist.
|
|
|
|
Es kann als Grundlage zum Aufbau einer sehr leistungsfähigen RDF-fähigen CEP-Engine verwendet werden\cite{cqels:stream}, da es im Gegensatz zu vielen anderen RDF-fähigen CEP-Engines die eigentliche Datenverarbeitung nicht eine externe Engine delegieren, sondern eine eigene Implementierung verwendet. Dadurch reduziert sich die benötigte Rechenleistung, da so keine übersetzende Schnittstelle zu einer externen Engine benötigt wird \cite{cqels:native}.
|
|
|
|
Eine im Paper \cite{cqels:stream} vorgestellte Lösung\footnote{Unter \url{http://graphofthings.org/debs2015/cqels.zip} ist ein VirtualBox-Image mit der Lösung zum Ausprobieren erhältlich. (Größe ca. 1,1 GiB)} zur Verarbeitung von RDF-Er\-eig\-nis\-da\-ten\-strö\-men mit einem CSPARQL-Dialekt konsumiert die Ereignisdaten über einen aus einer Datei lesenden CSV-Reader und schreibt die Ergebnisse der Verarbeitung über einen CSV-Writer in eine Datei, wobei die Engine intern mit RDF-Daten arbeitet, die von Reader und Writer jeweils konvertiert werden. Da es sich bei CQELS um ein Framework handelt\cite{cqels:native} ist im Gegensatz zu einer fertigen CEP-Engine zur Umsetzung eines Szenarios mit einem erhöhten Aufwand zu rechnen. Dafür punktet es im Vergleich zu klassischen, nicht RDF-fähigen CEP-Engines wie beispielsweise Esper mit einer hohen Performance\cite{cqels:stream}.
|
|
|
|
|
|
\section{C-SPARQL-Engine}
|
|
Die C-SPARQL-Engine wurde vom Polytechnikum Mailand (Italien) entwickelt; ein erstes Paper erschien im Jahr 2009\cite{barbieri:csparql}. Sie wurde zur Verarbeitung von RDF-Datenströmen im Rahmen eines Forschungsprojektes\cite{barbieri:csparql} in der Sprache Java entwickelt und bietet einen eigenen CSPARQL-Dialekt zur Formulierung von CEP-Regeln an, in denen direkt Bezug auf lokal vorhandenes Domänenwissen genommen werden kann. Weiterhin beinhaltet sie eine Implementierung von Reasoning auf RDFS-Vokabular, wie \cite{barbieri:reasoning} beschreibt.
|
|
|
|
Ein \enquote{Hello World}-Softwarepaket zur Demonstration der Engine, welches unter \url{http://streamreasoning.org/resources/c-sparql} zum Download angeboten wird, beinhaltet ein Eclipse/Maven-Projekt, welches Einsteigern einen ersten Überblick verschafft und leicht für eigene Zwecke angepasst werden kann. Da die Engine auf Software wie Apache Jena zum Speichern von RDF-Daten, Sesame zur Analyse und Abfrage von RDF-Daten via SPARQL, und die bekannte CEP-Engine Esper aufbaut, sind für die verwendeten Basistechnologien bereits gute Dokumentationen erhältlich.
|
|
|
|
|
|
\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 Gut erkennbarer Workflow zur Verwendung der Engine
|
|
\item Verwendung wenig verschiedener Programmiersprachen
|
|
\item Verwendung sehr verbreiteter Programmiersprachen
|
|
\item Transparente Implementierung der Engine durch Verwendung bekannter Technologien
|
|
\end{itemize}
|
|
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.
|
|
|
|
|
|
\chapter{CEP auf RDF-Datenströmen anhand der C-SPARQL Engine}
|
|
Nachdem die Wahl der CEP-Engine auf die C-SPARQL-Engine gefallen ist, sollen in diesem Kapitel nun ihre Möglichkeiten zur Verarbeitung von RDF-Datenströmen beleuchtet werden.
|
|
|
|
|
|
\section{Ereignisse}
|
|
Ereignisse werden aufgrund der Nutzung von RDF-Datenströmen als Transportmedium nun durch RDF-Tupel beschrieben. Diese tragen neben den typischen Inhalten von Tripeln (Subjekt, Prädikat und Objekt) nun eine vierte Information mit sich: den Zeitstempel, zu dem das Ereignis ausgelöst wurde. Da die Tupel nun mit dem Zeitstempel insgesamt vier Angaben enthalten, werden sie als \emph{Quadrupel} bezeichnet.
|
|
|
|
Um die Ereignisquadrupel trotz identischer Ereignistypen oder Zeitstempel voneinander unterscheiden zu können, ist es nötig, die Ereignisse mit einer eindeutigen ID zu versehen. Um dies zu erreichen, werden die einzelnen Ereignisse als eigene, separate Subjekte in RDF repräsentiert. Dadurch erhalten alle Quadrupel eines Ereignisses eine eindeutige Zuordnung zu ihrem Ereignissubjekt.
|
|
|
|
Um dies zu verdeutlichen folgt nun ein kleines Beispiel. Gegeben seien zwei beispielhafte Ereignisse mit Statusdaten über einen PKW. Listing~\ref{lst:sample_abstract_event_data} zeigt diese beiden Ereignisse in abstrakter Notation.
|
|
\begin{lstlisting}[caption={Zwei Statusereignisse eines PKW in abstrakter Notation},label={lst:sample_abstract_event_data}]
|
|
CarStatusEvent {
|
|
ID: 324,
|
|
timestamp: 1344829400,
|
|
relatedCar: ->[Car(ID: 0)],
|
|
speed: 63
|
|
}
|
|
|
|
CarStatusEvent {
|
|
ID: 325,
|
|
timestamp: 1344829405,
|
|
relatedCar: ->[Car(ID: 0)],
|
|
speed: 75
|
|
}
|
|
\end{lstlisting}
|
|
|
|
Wie aus Listing~\ref{lst:sample_abstract_event_data} zu erkennen ist, ist jedes Ereignis ein eigenes Objekt, welches alle für sich relevanten Daten entweder direkt oder als Zeiger auf andere Objekte enthalten kann. Um diese über RDF-Datenströme zu transportieren, müssen diese Ereignisse mit RDF-Quadrupeln beschrieben werden. Listing~\ref{lst:sample_event_rdf_quads} zeigt die Beschreibung der Ereignisse aus Listing~\ref{lst:sample_abstract_event_data} mit RDF-Quadrupeln.
|
|
\begin{lstlisting}[caption={RDF-Quadrupel mit Zeitstempeln beschreiben zwei Ereignisse eines PKW},label={lst:sample_event_rdf_quads}]
|
|
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
|
|
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
|
|
@prefix carOnt: <http://example.org/carSim/carSimulationOntology#> .
|
|
@prefix event: <http://example.org/carSim/objects/event#> .
|
|
|
|
(1344829400) event:324 rdf:type carOnt:CarStatusEvent .
|
|
(1344829400) event:324 carOnt:relatedCar car:0 .
|
|
(1344829400) event:324 carOnt:speed 63 .
|
|
|
|
(1344829405) event:325 rdf:type carOnt:CarStatusEvent .
|
|
(1344829405) event:325 carOnt:relatedCar car:0 .
|
|
(1344829405) event:325 carOnt:speed 75 .
|
|
\end{lstlisting}
|
|
Über RDF-Ereignisdatenströme ausgelieferte Ereignisdaten, die zur Verarbeitung einer RDF-fähigen CEP-Engine zugeführt werden, sind von der Struktur her angelehnt an die Beispielereignisse aus Listing~\ref{lst:sample_abstract_event_data} aufgebaut.
|
|
|
|
|
|
\section{Sprachkonzepte für CEP-Regeln}
|
|
Um die Ereignisdatenströme von RDF-Quadrupeln nun in der C-SPARQL-Engine verarbeiten zu können, werden CEP-Regeln benötigt, die im eigentlichen Verarbeitungsprozess verwendet werden, um die Ereignisdaten auszuwerten. Diese Regeln beschreiben Bedingungen, auf die sie matchen, sowie Aktionen, die ausgeführt werden sollen, wenn die Regel matcht. In abstrakter Notation sieht dies wie folgt aus:
|
|
\begin{lstlisting}[label={lst:sample_abstract_cep_rule}, caption={Abstrakte Struktur einer CEP-Regel}]
|
|
CONDITION (Event1 as e1, Event2 as e2)[within last 10min]
|
|
e1.foo > 500 AND e2.origin != "Mars"
|
|
ACTION
|
|
create new Event3(foo=(e1.baz+e2.baz/3), bar=e2.origin)
|
|
\end{lstlisting}
|
|
|
|
|
|
\subsection{CSPARQL als Sprache für CEP-Regeln}
|
|
\todo{Und so weiter \dots}
|
|
|
|
\paragraph{Sliding Windows}
|
|
\todo{Und so weiter \dots}
|
|
|
|
\paragraph{Aggregation von Ereignissen}
|
|
\todo{Und so weiter \dots}
|
|
|
|
\paragraph{Mustererkennung}
|
|
\todo{Und so weiter \dots}
|
|
|
|
\subsection{Auslösen von Aktionen}
|
|
Erzeugen von Ereignissen innerhalb von CSPARQL-Queries. Hinweise auf Möglichkeit der Auslösung von Reaktionen beim Beobachten der Abfrageergebnisse.
|
|
|
|
|
|
|
|
\section{Einbindung von Domänenwissen}
|
|
Integration von Hintergrundwissen findet live im Query statt ohne extra Klimmzüge, da alles innerhalb der CSPARQL-Queries abzufragen ist.
|
|
|
|
|
|
\section{Reasoning auf RDF-Datenströmen}
|
|
\begin{itemize}
|
|
\item Bei Stefan Lier mal gucken
|
|
\item Reasoning auf RDFS-Level kann die C-SPARQL-Engine definitiv.
|
|
\end{itemize}
|
|
|
|
|
|
\chapter{Umsetzung des Beispielszenarios}
|
|
|
|
\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 vielleicht etwas Reasoning eingeschaltet und dessen Ergebnisse begutachtet.}
|
|
|
|
In diesem Kapitel wird die C-SPARQL-Engine konkret vorgestellt und verwendet um das Beispielszenario aus Kapitel~\ref{cpt:scenario} umzusetzen. Dafür werden die Anforderungen des Szenarios einzeln betrachtet, die Ereignisdatenströme und der ganze Kram, der da mit dranhängt um dann eine Lösung zu konzipieren und implementieren.
|
|
|
|
\begin{itemize}
|
|
\item RDF-Datenströme
|
|
\item Beispielszenario
|
|
\item Umsetzung mit C-SPARQL
|
|
\item Nötiger Code für das Grundsetup der Engine, Generatoren und co
|
|
\item Konkreter Blick auf die CSPARQL-Queries
|
|
\item Ergebnisse der Abfragen
|
|
\end{itemize}
|
|
|
|
|
|
\section{Nutzung der C-SPARQL Engine in Java}
|
|
|
|
\todo{TBD}
|
|
Im Folgenden wird auf die praktische Anwendung der C-SPARQL-Engine in einem Java-Projekt eingegangen.
|
|
|
|
\begin{itemize}
|
|
\item Welche technischen Strukturen sieht die Engine vor,
|
|
\item wie werden Datenströme zugeführt,
|
|
\item wie werden Queries erzeugt, registriert und beobachtet,
|
|
\item was muss dabei beachtet werden, welche Fallstricke gibt es (zur Zeit)
|
|
\item wie wird Hintergrundwissen eingespeist und zur Laufzeit aktualisiert,
|
|
\item welche Schritte sind nötig um RDFS-Reasoning zu nutzen?
|
|
\item Und natürlich immer wieder mittendrin: Wie sehen die Ergebnisse aus, die dabei entstehen?
|
|
\end{itemize}
|
|
|
|
\todo{Die einzelnen Sections entstehen beim Schreiben der Texte.}
|
|
|
|
|
|
\section{Bewertung/Ergebnis}
|
|
|
|
\begin{itemize}
|
|
\item (Konnten die gestellten Anforderungen erfüllt werden?)
|
|
\item Was konnte erreicht werden?
|
|
\item Was konnte nicht erreicht werden?
|
|
\item Gab es Schwierigkeiten? [Guter Zeitpunkt, um hier f:timestamp() vs Tripel mit Literals zu erwähnen]
|
|
\item Wie hoch war der Aufwand?
|
|
\item Wie steht es um die Qualität der Ergebnisse?
|
|
\item Eventuell ein Blick auf die Performance?
|
|
\end{itemize}
|
|
|
|
|
|
\chapter{Fazit}
|
|
|
|
\todo{Zusammenfassungsüberleitung über das Kapitel}
|
|
|
|
\begin{itemize}
|
|
\item Bewertung der Ergebnisse im Abgleich mit den Anforderungen und dem Aufwand?
|
|
\item Ist es für die Anforderungen (und mehr) praxistauglich?
|
|
\item Oder gibt es zur Zeit bessere Alternativen?
|
|
\end{itemize}
|
|
|
|
|
|
\chapter{Ausblick}
|
|
|
|
\todo{Eventuell mit Fazit zusammenführen, wenn es nicht zu groß wird.}
|
|
|
|
\begin{itemize}
|
|
\item Kann man mit der Engine in Zukunft noch mehr schaffen?
|
|
\item Wie steht es um Reasoning? Geht das? Wenn ja, nur RDFS oder auch OWL? \todo{Ist der Unterschied zwischen den Beiden fürs erste sehr wichtig oder führt das zu weit?}
|
|
\end{itemize}
|
|
|
|
Vielleicht geht das mit dem Reasoning später ja noch besser --- aktueller Stand ist noch limitiert, aber es wird fleißig daran geforscht \dots
|
|
|
|
|
|
\chapter*{Dummy-Kapitel für Tests und Notizen}
|
|
|
|
\todo{Spätestens vor dem Druck muss dieses Kapitel raus aus dem Dokument.}
|
|
|
|
Fähigkeitenliste, die auf C-SPARQL-Engine zutrifft. Eventuell für den Vergleich von CEP-Engines hier mal gucken, was davon relevant und interessant ist.
|
|
\begin{itemize}
|
|
\item Verarbeitung von mehreren Ereignisströmen
|
|
\item Verknüpfung von Ereignissen
|
|
\item Konstruktion neuer Ereignisse
|
|
\item Sliding/Tumbling Windows
|
|
\item Mustererkennung (Abfolge, Präsenz/Absenz von Ereignissen [zeitlicher Abstand])
|
|
\item \enquote{COMPUTE EVERY} (Neuberechnung in festen Intervallen)
|
|
\item Ausführen von benutzerdefiniertem Code
|
|
\item Integration von Hintergrundwissen [aus weiteren Quellen]
|
|
\item Aggregationsfunktionen über mehrere Ereignisse (Sum, Avg, ...)
|
|
\item Vergleichsoperatoren für Selektionskriterien
|
|
\item Bonuspunkte: Reasoning (Logikoperationen und Schlussfolgerungen)
|
|
\end{itemize}
|
|
|
|
\textcolor{red}{Dieses Kapitel fliegt am Ende natürlich raus.}
|
|
|
|
Sil-ben ge-trenn-t mit ei-nem Strich
|
|
|
|
C--SPARQL (Zwei Striche ergeben einen Bindestrich)
|
|
|
|
Und dann --- neben vielen anderen Zeichen --- gibt es mit drei Strichen den Gedankenstrich.
|
|
|
|
Mit \enquote{enquote} wird Text in Anführungszeichen gesetzt, aber manchmal ist vielleicht der Einsatz von \texttt{texttt} sinnvoll. Im \textbf{Notfall} kann auch \textbf{textbf} genutzt werden. Dann gibt es noch \textit{textit}, \textsc{textsc}, \textsf{textsf} und \textsl{textsl}.
|
|
|
|
Quellenreferenzen
|
|
\begin{itemize}
|
|
\item \cite{hsh:cep}[Einstieg in CEP mit Beispielen aus Esper-Welt]
|
|
\item \cite{hsh:integrating}[Esper vs C-SPARQL CEP ohne Reasoning]
|
|
\item \cite{barbieri:reasoning}[Ansatz für Reasoning auf RDF-Strömen mit C-SPARQL]
|
|
\item \cite{barbieri:querying}[Grundlagen C-SPARQL für CEP]
|
|
\item \cite{cqels:stream}[CQELS-Paper]
|
|
\item \cite{ep:etalis}[ETALIS-Paper]
|
|
\item \cite{ep:unified}[EP-SPARQL-Paper]
|
|
\item \cite{man:owl}[Owl Reasoning Examples]
|
|
\item \cite{w3c:sparql}[W3C zu SPARQL]
|
|
\item \cite{iao:esper}[Marktübersicht Real-Time Monitoring Software]
|
|
\item \cite{w3c:turtle}[Die Turtle-Notation]
|
|
\item \cite{hitzler:semanticweb}[Grundlagen Semantic Web]
|
|
\item \cite{cqels:native}[Mehr CQELS]
|
|
\item \cite{barbieri:csparql}[Erstes C-SPARQL Proposal]
|
|
\end{itemize}
|
|
|
|
|
|
%%% Ende inhaltlicher Inhalt! %%%
|
|
|
|
% Literaturverzeichnis
|
|
% Schlüssel als Buchstaben
|
|
\bibliographystyle{alpha}
|
|
\bibliography{Literaturverweise}
|
|
|
|
\end{document}
|
|
% Nothing beyond this line!
|
|
|
|
|
|
% Referenz auf Bibtex mit Kommentar
|
|
% \cite{robbins:gawk}[Siehe ab S.95]
|
|
|
|
% Einbinden von Tex-Files
|
|
%\input{abkuerz.tex}
|
|
%\input{einfuehrung.tex}
|
|
|
|
% Einbinden von größeren Tex-Files, z.B. Kapiteln
|
|
%\include{normen}
|
|
%\include{aufbau}
|
|
%\include{zitieren}
|
|
%\include{form}
|
|
%\include{allgtips}
|