introduction.tex

   1 \chapter{Introduction}
   2 Sie führt in die Problematik ein, skizziert die Motivation und
   3 Zielsetzung sowie das geplante Vorgehen und die angestrebten
   4 Ergebnisse und sollte ca. 1 - 2 Seiten umfassen.\\
   5
   6 \section{Motivation}
   7 As estimated in 2007 \cite{deepweb}, publicly available databases contained
   8 up to 500 times more data than the static web and roughly 70 \% of all
   9 websites were backed by relational databases back then.
  10 As hardware has become cheaper yet more powerful, open source tools have
  11 become more and more widespread and the web has gotten more and more dynamic
  12 and interactive, it's likely that these numbers have even increased since then.
  13 This makes the publication of available data in a structured,
  14 machine-processable form
  15 and its retrieval with eligible software (Ontology based data access, OBDA)
  16 an interesting topic.
  17 This vision emerged as early as TODO and was entitled with the term ``semantic web''
  18 by Tim Berners-Lee \cite{thesemanticweb}.
  19 Definitely, the automatic translation of relational databases to RDF
  20 or similar representations of structured information is
  21 an integral part of the success of the semantic web \cite{deepweb}.
  22 This automatic translation process is commonly called ``bootstrapping''.
  23
  24 Early work regarding the development of bootstrapping systems includes TODO.
  25 Today, the pure translation process is a relatively well understood topic,
  26 ranging from the rather simple direct mapping approach \cite{dirm} to TODO.
  27 On the other hand, the handling of the complexity introduced by these approaches
  28 and the use of sophisticated tools to perform various related tasks
  29 meanwhile has become a significant challenge in its own right \cite{eng}.
  30 Besides the parametrization of the tools in use, this includes the management of
  31 the several kinds of artifacts accruing during the process, possibly needed in
  32 different versions and formats for the use of different tools and output formats,
  33 while also taking changing input data into account \cite{eng}.
  34 Skjæveland and others therefore suggested an approach using a
  35 declarative description of the data to be mapped, concentrating in one place
  36 all the information needed to coordinate the bootstrapping process
  37 and to drive the entire tool chain \cite{eng}.
  38
  39 \section{Approach}
  40 This thesis describes the development of a specification language to serialize
  41 the declarative specification of the bootstrapping process and of a
  42 software to in turn bootstrap it from a relational database schema.
  43 After the tasks they accomplish,
  44 the specification language was called ``OBDA Specification Language'' (``OSL'')
  45 and the software bootstrapping the specification was called ``db2osl''.
  46
  47 Using a declarative specification makes the entire bootstrapping process a
  48 two-step-procedure: First, the OBDA specification is derived from the
  49 database schema using \myprog{}.
  50 It specifies the actual bootstrapping process in a very general way,
  51 so it only has to be recreated when the database schema changes.
  52 The second step is to use the OBDA specification to coordinate and drive the
  53 actual bootstrapping process.
  54 The development of a software that uses the OBDA specification
  55 to perform this second step currently is subject to ongoing work.
  56 It will be able to be parameterized accordingly to support different output
  57 formats, tools, tool versions and application ranges.
  58 \\\\TODO: illustration of overall process
  59
  60 \section{Requirements and goals}
  61 The final system shall be able to cleanly fit into existing bootstrapping systems
  62 while being easy to use, taking the burden of dealing with \osl{} specifications
  63 manually from its users instead of adding even more complexity to the process.
  64 To achieve the former goal, use of existing tools, languages and conventions was
  65 made wherever possible.
  66 To fit into the environment used in the OPTIQUE project TODO it is ultimately
  67 part of, Java was used for the bootstrapping software.
  68 Care was taken to design it to be modular and flexible, making it
  69 usable not only as a whole but also as a collection of independent components
  70 possibly serving as the basis for a program library in the future.
  71 To further support this aim TODO and to make the software more easily
  72 understandable and extensible, it was documented carefully and thoroughly.
  73
  74 As the software will be maintained by diverse people after its development and will
  75 likely be subject to changes, general code quality was also an issue to consider.
  76 Following good object-oriented software development practice TODO,
  77 real world artifacts like database schemas, database tables, columns, keys,
  78 OBDA specifications et cetera were modeled as software objects, provided with a
  79 carefully chosen set of operations to manipulate them and make them collaborate.
  80 Scarce, informative comments were inserted at places of higher complexity and to
  81 expose logical subdivisions, but care was taken to use ``speaking code'' in favor
  82 of rampant comments.
  83 Complex, misleading and hard-to-use interfaces were avoided wherever possible.
  84 External software libraries employed were chosen to be stable, specific,
  85 well structured, publicly available and ideally in wide use.