ca257079d3eed16a6cf3e4c4aa6d4219a8ddf70a
[u/philim/db2osl_thesis.git] / background.tex
1 \chapter{Background and related work}
2
3 \section{Background}
4 \subsection{Ontology-based data access (OBDA)}
5 \label{obda}
6 TODO: References
7
8 Storing data in relational databases is a very common proceeding, since the
9 notion of a relational database is comprehensible and widely known, while the
10 required software is widely available both commercially and as open-source
11 software.
12 Thus, it is easy for a domain expert to set up and populate a database.
13 Furthermore, relational databases provide significant advantages concerning
14 performance, data consistency and integrity, integration abilities, support
15 and general prominence.
16 These topics definitely played a major role in the success and the extensive
17 exploration that databases discovered, up to the degree that these are the
18 main fields the strengths of databases are seen in.
19 Many -- if not all -- of these strengths trace back to the relatively fixed
20 and rigid schema databases embody: a well-defined database schema imposing
21 strong and clear cut constraints on the contained data.
22
23 However, this principle also induces notable disadvantages.
24 The database schema, although theoretically changeable, constitutes a
25 significant burden on TODO the representation of data of dynamic
26 environments, incomplete data or changing requirements,
27 especially when dealing with large amounts of data.
28 The resulting representation of data in unintuitive, suboptimal schemata
29 makes the use of prolonged and complex query constructs inevitable, which
30 lets more elaborate queries quickly become unmanageable for non-experts
31 and time-consuming and error-prone even for experts.
32 Ontologies, on the other hand, are much more flexible regarding incomplete
33 data or changing requirements or environments and allow for much more
34 intuitive and abstract query systems, while still being a quite
35 comprehensible formalism
36 (see Section~\ref{ontologies} for publications describing
37 ontologies and the semantic web).
38 Besides, ontologies provide support for different data records referencing
39 the same entity, while databases do not \cite{eng}, and for the deduction of
40 implicit information \cite{eng}, which with common database systems, if at
41 all, is at least not possible out of the box and in an easy manner.
42 Often, however, relational databases are preferred for their advantages
43 (although the availability of cheaper yet more powerful hardware in some
44 cases offsets these) or simply erroneously.
45 Besides, in some cases, the migration to ontology-based systems,
46 even if beneficial, is to costly to be seriously considered.
47 %, often due to the large amounts of data that would have to be converted.
48
49 Ontology-based data access often provides a solution to this collision of
50 interests:
51 By adding an ontology-based front-end processing the queries that is
52 sensibly mapped to the data representation,
53 the querying facilities of ontology-based systems are introduced,
54 and changes in the data representation most often can be carried out
55 without breaking existing queries; only the mapping has to be changed
56 -- in a one-time effort -- and only when it introduces changes in the way
57 it presents existing structures to the user, existing queries have to be
58 modified.
59 The creation of these mappings in turn can happen computer-aided or, in
60 simple cases or to a certain degree of completeness and accuracy,
61 the mappings can be completely bootstrapped.
62
63 Moreover, in cases where it is to costly or for other cases infeasible
64 to carry out a complete data duplication, the data can remain in the
65 underlying database as is and the query front-end merely acts as an
66 interface transforming the query into a database query \cite{eng} by
67 making use of a backward-chaining technique called \emph{query rewriting}
68 \cite{eng}.
69 This approach is called \emph{virtual OBDA} or \emph{virtual RDF view}
70 \cite{eng} and is illustrated in Figure~\ref{back_subfig_virtual}.
71 The oppositional approach of duplicating all data is called
72 \emph{materialized OBDA} or \emph{materialized RDF view} and is
73 illustrated in Figure~\ref{back_subfig_materialized}.
74 Virtual OBDA provides limited abilities compared to materialized OBDA
75 in that it does not allow for decoupling from the source data by for
76 example adding inferred information or applying elaborate transformations
77 and does not support ``fragments of OWL for which query
78 rewriting is not a complete deduction method'' \cite{eng}.
79 However, the response time of systems is hard to predict solely from the
80 architectural approach used, so if it is critical, several systems should
81 be prototyped and evaluated upfront on what are expected to be
82 typical queries \cite{eng}.
83
84 \begin{figure}[H]\begin{center}
85         \begin{subfigure}[b]{0.8\textwidth}
86                         \includegraphics[scale=1.2]{Images/bootstrapping_materialized.pdf}
87                         \caption{OBDA system architecture with materialized \name{RDF} view}
88                         \label{back_subfig_materialized}
89         \end{subfigure}\\~\\
90         \begin{subfigure}[b]{0.8\textwidth}
91                         \includegraphics[scale=1.2]{Images/bootstrapping_virtual.pdf}
92                         \caption{OBDA system architecture with a virtual \name{RDF} view}
93                         \label{back_subfig_virtual}
94         \end{subfigure}
95         \caption[The two basic OBDA system architectures]
96                 {The two basic OBDA system architectures:
97                 materialized and virtual \name{RDF} views (from \cite{eng})}
98         \label{back_fig_bootstrapping}
99 \end{center}\end{figure}
100
101 Finally, it has to be mentioned, that ontology-based data access is not
102 limited to databases.
103 Although this is the most common scenario and the only one this thesis
104 deals with, ontology-based data access also works with other sources of
105 structured information, like \name{ODS}, \name{XLS} or \name{CSV} files,
106 though some additional preparation might be necessary in these cases \cite{eng}.
107
108 \subsection{OBDA specifications}
109 As mentioned in Section~\fullref{motivation}, the sole bootstrapping of
110 \name{RDF} triples \cite{rdf} or other forms of structured information
111 from relational database schemata is a relatively well understood topic.
112 This is outlined more comprehensively in Section~\fullref{related}.
113
114 Nonetheless, bootstrapping remains an elaborate process involving complex
115 tools to be invoked -- possibly in different versions and configurations
116 and processing different formats -- and working on changing input data
117 \cite{eng}.
118 This is why Skjæveland and others proposed the introduction of OBDA
119 specifications centralizing the task of driving these tools and
120 to gather in one place all the information describing the desired mapping
121 between the source database and the target ontology \cite{eng}.
122 As described in Section~\fullref{related}, their approach is the
123 foundation of this thesis, which describes and specifies a format for
124 storing and exchanging such OBDA specifications -- the \oslboth{} -- and
125 introduces a tool that in turn automatically bootstraps OBDA Specifications
126 from relational database schemata -- the \myprog{} software.
127
128 The bootstrapping process using OBDA specifications and \myprog{} is
129 illustrated in Figure~\ref{intro_fig_bootstrapping}
130 in Section~\fullref{approach}.
131
132 \subsection{The \name{OPTIQUE} project}
133 The problems addressed in Section~\fullref{motivation} are a big issue
134 inter alia TODO in the oil and gas industry:
135 $30 \%$ to $70 \%$ of the working time of engineers is spent on collecting
136 data or assessing its quality \cite{crompton}.
137 This led to the origination of the \name{OPTIQUE} project in TODO which
138 ``advocates for a next generation of the well known Ontology-Based Data Access
139 (OBDA) approach to address the data access problem [...] [aiming] at
140 solutions that reduce the cost of data access dramatically'' \cite{optique}.
141 Thus, the \name{OPTIQUE} project tries to reach exactly the benefits a
142 well-developed OBDA system can provide (explained in Section~\ref{obda}):
143 an easy end-user access to data without knowing about its structuring
144 while taking advantage of automatic translations \cite{optique2}.
145 In doing so, ascertained shortcomings of existing OBDA systems were addressed:
146 \emph{usability} (for example the need to use formal query languages),
147 \emph{costly prerequisites} (consider, for example, the disadvantages
148 of materialized OBDA described in Section~\ref{obda}) and
149 \emph{efficiency} (which was perceived as being insufficiently addressed
150 in previous approaches) \cite{optique}.
151
152 \section{Related work}
153 \label{related}
154 \subsection{Ontologies and the semantic web -- publications}
155 \label{ontologies}
156
157 \subsection{OBDA specifications -- publications}
158 A publication building the foundation of the work presented in this thesis, is
159 the summarizing and benchmarking work on OBDA specifications by Skjæveland et al.
160 \cite{eng}, the group that developed them in their present form.
161
162 \subsection{OBDA systems -- publications}
163
164 \subsection{General ontology bootstrapping -- publications}
165 Skjæveland, Lian and Horrocks \cite{npd} provided an exemplifying description of
166 the transformation of the \emph{NPD FactPages}, an enormous collection of data
167 related to oil drilling on the Norwegian continental shelf, provided by
168 the Norwegian Petroleum Dictorate (NPD).
169
170 Sequeda et al. \cite{survey} provided an overview over different
171 direct mapping approaches.
172
173 Sequeda, Arenas and Miranker \cite{ondirm} \cite{autodirm}
174 describe the direct mapping of relational databases to \name{RDF}
175 and \name{OWL} formally.
176
177 Stojanovic, Stojanovic and Volz \cite{sac} published a formal description of
178 the mapping of relational databases onto ontology-based structures, describing
179 concepts preceding and/or supplementing \name{OWL} and using \name{F-LOGIC} TODO
180 as target language.
181
182 \subsection{The \name{OPTIQUE} project -- publications}
183 Calvanese et al. \cite{optique2} presented the \name{OPTIQUE} project including
184 its underlying OBDA system and showed limitations of current OBDA systems.
185
186 Kharlamov et al. \cite{optique} described the first version of the \name{OPTIQUE}
187 system, customized for use with the \emph{NPD FactPages} of the
188 Norwegian Petroleum Dictorate (NPD).
189
190 Skjæveland and Lian \cite{benefits} summarized the benefits of and the
191 proceeding for converting the \name{NPD FactPages} to linked data \cite{linked}
192 and discuss associated terms like linked data, URIs, \name{RDF} and
193 \name{SPARQL}.
194
195 \subsection{Alternative approaches -- publications}
196 Barrasa, Corcho and P{\'e}rez \cite{r2o} proposed a declarative mapping
197 language -- \name{r2o} -- able to express a mapping between a relational
198 database and ontologies represented in the \name{OWL} and \name{RDF} formats.
199 This approach however aims at connecting existing databases
200 and existing ontologies.
201
202 TODO: R2RML, SQL2SW