[TASK] Generic commit.
This commit is contained in:
parent
22d3e5b7a7
commit
9d8b08a71e
|
|
@ -320,7 +320,7 @@ In Listing~\ref{lst:sample_rdfs_data} werden zunächst die beiden Klassen \textt
|
|||
|
||||
\paragraph{OWL-Ontologien}
|
||||
\todo{Mehr Inhalt! Das ist so zu wenig!}
|
||||
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 mächtigere Sprachkonstrukte, 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.
|
||||
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 mächtigere Sprachkonstrukte, um feiner granulare Regeln für Objektklassen und Attribute aufzustellen. Attribute können beispielsweise transitiv oder symmetrisch wirkend definiert werden, wodurch die Verwendung solcher Attribute deutlich mehr implizite Aussagekraft hat. Auch sind spezifische Einschränkungen für Attributtypen auf Datentypebene möglich. 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.
|
||||
|
|
@ -339,10 +339,7 @@ Sollte es nötig sein, für eigene Terminologie eine Ontologie zu erzeugen, so i
|
|||
\subsection{Anreicherung von RDF-Daten durch Reasoning}\label{cpt:reasoning}
|
||||
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}.
|
||||
|
||||
\todo{Reasoning anhand von RDFS-TBox erklären: transitive und symmetrische Attribute sind leichter zu greifen!}
|
||||
|
||||
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{Beispiel zu komplex, muss ersetzt werden!}
|
||||
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, da PKW eine Unterklasse der Klasse Fahrzeug ist.}. Analog hierzu ist es auch möglich, übergeordnete Beziehungen aus vorhandenen Beziehungen abzuleiten: \enquote{Max fährt sein Auto. Da man zum Fahren eines Autos (meist) in dem Auto sitzen muss, folgt daraus: Max sitzt in seinem Auto.}.
|
||||
|
||||
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}.
|
||||
|
||||
|
|
@ -961,6 +958,22 @@ 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-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.
|
||||
|
||||
|
||||
\begin{lstlisting}[label={reasoning_tbox},caption={TBox mit Klassen und Attributdefinitionen aus RDFS}]
|
||||
:CarWearEvent rdf:type rdfs:Class .
|
||||
:CarBrakeWearEvent rdf:type rdfs:Class .
|
||||
:CarBrakeWearEvent rdfs:subClassOf :CarWearEvent .
|
||||
\end{lstlisting}
|
||||
|
||||
\begin{lstlisting}[label={reasoning_abox},caption={ABox mit Fakten, die sich auf die TBox aus Listing~\ref{reasoning_tbox} beziehen}]
|
||||
|
||||
\end{lstlisting}
|
||||
|
||||
\begin{lstlisting}[label={reasoning_result},caption={Durch Reasoning ermitteltes, implizites Wissen}]
|
||||
|
||||
\end{lstlisting}
|
||||
|
||||
|
||||
Um Reasoning mit der C-SPARQL-Engine zu nutzen, müssen die folgenden zwei Schritte durchgeführt werden:
|
||||
\paragraph{Aktivierung der Inferenz}
|
||||
Bei der Registrierung einer C-SPARQL-Abfrage an der Engine muss angegeben werden, ob Inferenz mit dem Reasoner für diesen Query verwendet werden soll. Die folgende Zeile zeigt diesen Schritt, wobei der zweite Parameter ausschlaggebend für die Aktivierung ist:
|
||||
|
|
@ -976,6 +989,8 @@ 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{Erläuterung der praktischen Ergebnisse von Reasoning auf RDF-Datenströmen}
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
|
@ -1039,7 +1054,8 @@ Im Folgenden wird auf die praktische Anwendung der C-SPARQL-Engine in einem Java
|
|||
\item Oder gibt es zur Zeit bessere Alternativen?
|
||||
\end{itemize}
|
||||
|
||||
Die Engine wurde in Version 0.9.6 verwendet, da in 0.9.7 einige Bugs enthalten sind, die dazu führen, dass sie nicht überall benutzbar ist. :-/
|
||||
Die Engine wurde in Version 0.9.6 verwendet, da in 0.9.7 einige Bugs enthalten sind, die dazu führen, dass sie nur eingeschränkt benutzbar ist.
|
||||
Weiterhin gibt es einige False Positives des Tokenizers für die C-SPARQL-Sprache, die unter anderem dazu führen, dass Bezeichner, die das Wort \enquote{Stream} enthalten, fälschlicherweise für das Schlüsselwort \texttt{STREAM} gehalten werden.
|
||||
|
||||
|
||||
\section{Ausblick}
|
||||
|
|
|
|||
Loading…
Reference in New Issue