introduction.tex

   1 \chapter{Introduction}
   2 \label{intro}
   3
   4 \section{Motivation}
   5 \label{motivation}
   6 As estimated in 2007 \cite{deepweb}, publicly available databases contained
   7 up to 500 times more data than the static web and roughly 70 \% of all
   8 websites were backed by relational databases back then.
   9 As hardware has become cheaper yet more powerful, open source tools have
  10 become more and more widespread and the web has gotten more and more dynamic
  11 and interactive, it's likely that these numbers have even increased since then.
  12 This makes the publication of available data in a structured, machine-processable
  13 form and its retrieval with eligible software an interesting topic.
  14 The most important formalism to represent structured data without the need of
  15 a fixed (database) schema is ontologies, and thus this approach is known
  16 under the term ``Ontology based data access'' (``OBDA'').
  17
  18 The vision of a machine-processable web emerged as early as 1989 \cite{web}
  19 and was entitled with the term ``semantic web''
  20 by Tim Berners-Lee in 1999 \cite{weavingweb}.
  21 Definitely, the automatic translation of relational databases to \name{RDF}
  22 \cite{rdf} or similar representations of structured information is
  23 an integral part of the success of the semantic web \cite{deepweb}.
  24 This automatic translation process is commonly called ``bootstrapping''.
  25
  26 Today, the pure bootstrapping process is a relatively well understood topic,
  27 ranging from the rather simple direct mapping approach \cite{dirm} to TODO.
  28 On the other hand, the handling of the complexity introduced by these approaches
  29 and the use of sophisticated tools to perform various related tasks
  30 meanwhile has become a significant challenge in its own right \cite{eng}.
  31 Besides the parametrization of the tools in use, this includes the management of
  32 the several kinds of artifacts accruing during the process, possibly needed in
  33 different versions and formats for the use of different tools and output formats,
  34 while also taking changing input data into account \cite{eng}.
  35 Skjæveland and others therefore suggested an approach using a
  36 declarative description of the data to be mapped, concentrating in one place
  37 all the information needed to coordinate the bootstrapping process
  38 and to drive the entire tool chain \cite{eng}.
  39
  40 \section{Approach}
  41 \label{approach}
  42 This thesis describes the development of a specification language to serialize
  43 the declarative specification of the bootstrapping process
  44 (see Section~\fullref{motivation}) and of a
  45 software to in turn bootstrap it from a relational database schema.
  46 After the tasks they accomplish,
  47 the specification language was called ``OBDA Specification Language'' (``OSL'')
  48 and the software bootstrapping the specification was called ``db2osl''.
  49
  50 Furthermore, this thesis suggests a scheme for generating the IRIs that
  51 occur in OBDA specification, identifying their parts \cite{eng}.
  52 Currently, this issue is only exemplified and there is room for improvement
  53 in that a simple and straight-forward approach can be used to generate
  54 IRIs for all constituents of OBDA specifications without introducing
  55 name clashes in corner cases.
  56 This approach is described in Section~\fullref{iris}.
  57
  58 Using a declarative specification makes the entire bootstrapping process a
  59 two-step-procedure, illustrated in Figure~\ref{intro_fig_bootstrapping}:
  60 First, the OBDA specification is derived from the
  61 database schema using \myprog{}.
  62 It specifies the actual bootstrapping process in a very general way,
  63 so it only has to be recreated when the database schema changes.
  64 The second step is to use the OBDA specification to coordinate and drive the
  65 actual bootstrapping process.
  66 The development of a software that uses the OBDA specification
  67 to perform this second step currently is subject to ongoing work.
  68 It will be able to be parameterized accordingly to support different output
  69 formats, tools, tool versions and application ranges.
  70
  71 \begin{figure}[H]\begin{center}
  72                 \includegraphics[scale=0.9]{Images/bootstrapping_illustration.pdf}
  73                 \caption[Illustration of the overall
  74                         bootstrapping process]{Illustration of the overall
  75                         bootstrapping process using a declarative OBDA specification}
  76                 \label{intro_fig_bootstrapping}
  77         \end{center}\end{figure}
  78
  79 \section{Requirements and goals}
  80 The final system shall be able to cleanly fit into existing bootstrapping systems
  81 while being easy to use, taking the burden of dealing with \osl{} specifications
  82 manually from its users instead of adding even more complexity to the process.
  83 To achieve these goals, use of existing tools, languages and conventions was
  84 made wherever possible.
  85 For example, the \osllong{} was defined to be a subset of \name{OWL}.
  86 This facilitates meeting the objective of a powerful, easy-to-use, flawless and
  87 well-documented language that can be extended and handled by existing tools.
  88
  89 To fit into the environment used in the \name{OPTIQUE} project \cite{optique2}
  90 it is ultimately part of, \name{Java} was used for the bootstrapping software.
  91 Care was taken to design it to be modular and flexible, making it
  92 usable not only as a whole but also as a collection of independent components,
  93 possibly serving as the basis for a program library in the future.
  94 To achieve this aim and to make the software more easily
  95 understandable and extensible, it was documented carefully and thoroughly.
  96
  97 As the software will be maintained by diverse people after its development and will
  98 likely be subject to changes, general code quality was also an issue to consider.
  99 Following good object-oriented software development practice \cite{str3},
 100 real world artifacts like database schemata, database tables, columns, keys,
 101 and OBDA specifications were modeled as software objects, provided with a
 102 carefully chosen set of operations to manipulate them and make them collaborate.
 103 This approach and other actions aiming at yielding clean code are described more
 104 thoroughly in Section~\fullref{code}, while
 105 the resulting structure of the software is discussed in Section~\fullref{arch}.