]>
Commit | Line | Data |
---|---|---|
c31df1ed PM |
1 | \section{Functionality} |
2 | \label{functionality} | |
002fa020 PM |
3 | As described in the \hyperref[intro]{introduction} of this thesis, |
4 | the \myprog{} software is | |
5 | a program automatically deriving an OBDA specification | |
6 | from a relational database schema, | |
c31df1ed | 7 | which then can be used by other tools to drive the actual bootstrapping process. |
45d598e9 PM |
8 | Its functionality is described in this section, |
9 | leaving out self-evident features, and is then listed completely. | |
b96bb723 PM |
10 | How this functionality is exposed to users is described in Section~\fullref{interface}. |
11 | The bootstrapping process using direct mapping as the core functionality | |
12 | of the software is described in Section~\ref{dirm}. | |
13 | ||
002fa020 | 14 | TODO: reference to OBDA topics |
c31df1ed | 15 | |
c31df1ed PM |
16 | The database schema is retrieved by connecting to an \name{SQL} database |
17 | and querying its schema information. | |
002fa020 | 18 | Parsing \name{SQL} scripts or \name{SQL} dumps currently is not supported. |
c31df1ed PM |
19 | %Naturally, authentication on the \name{SQL} server is supported, also by |
20 | %interactively querying for passwords while hiding the typed input. | |
21 | The databases to derive information from can be specified by regular expressions, | |
22 | while there are also options to use other databases than specified or even | |
23 | other database servers, taken from a list of hard-coded strings. | |
24 | While these features may not seem to carry real benefit at the first glance, | |
002fa020 | 25 | they proved to be useful for testing purposes, especially since the retrieval of a |
b96bb723 PM |
26 | database schema can take some time TODO (see Section~\fullref{stats}). |
27 | For the same purpose, \myprog{} allows the processing of a hard-coded | |
28 | example database schema. | |
c31df1ed | 29 | |
b96bb723 PM |
30 | In addition to \osl{} output, a low-level output format containing information on all |
31 | fields of the underlying objects is supported, which is useful for debugging | |
c31df1ed PM |
32 | (however, this feature has to be enabled via one slight change in the source code). |
33 | To allow for some customization, the insertion of an own \osl{} header is supported | |
b96bb723 PM |
34 | (for more information on the \osl{} header, see the specification of the \osllong{} |
35 | in Section~\ref{osl_spec}). | |
c31df1ed PM |
36 | If the standard \osl{} header is used, it is by default loaded from a hard-coded copy, |
37 | so bootstrapping information from a database server running locally or from the hard-coded | |
38 | example schema requires no Internet connection | |
39 | (simply inserting the \code{owl:imports} statement of course would not anyway, | |
40 | but the generated underlying ontology is always checked for consistency with the | |
41 | \osl{} header to prevent the generation of invalid output). | |
42 | ||
43 | The \myprog{} software can be used both in an interactive and in a non-interactive mode, | |
44 | while skipping a database or a database server or aborting the entire bootstrapping process | |
45 | is possible in either mode. | |
46 | Multiple database servers can be specified for a bootstrapping operation, | |
47 | which then are checked in order for a matching database, | |
48 | allowing to make use of mirrors or fallback servers. | |
49 | Additionally, multiple bootstrapping operations can be specified to be performed in sequence | |
50 | with one invocation of \myprog{}, while all features and settings previously described | |
51 | are enabled, disabled or set per operation. | |
52 | Finally, a help text can be displayed which describes the usage of \myprog{} including the | |
53 | description of all command-line arguments. | |
54 | ||
c31df1ed PM |
55 | The functionality of the \myprog{} software can be summarized as follows: |
56 | ||
57 | \begin{itemize} | |
58 | \item Bootstrap one or more OBDA specifications from a database schema | |
59 | by connecting to an \name{SQL} database server | |
60 | \item Specify a custom port, login and password for the database server | |
61 | \item Ask for passwords interactively (before starting any bootstrapping | |
62 | operation), hide them if desired | |
63 | \item Specify database names by regular expressions | |
64 | \item Process an arbitrary database if the specified database | |
65 | could not be found or unconditionally | |
66 | \item Connect to a database server containing example databases | |
67 | without having to specify any further details | |
68 | \item Process a hard-coded example database schema | |
69 | without having to specify any further details | |
b96bb723 | 70 | \item Use the \osl{} format described in Chapter~\fullref{osl} |
c31df1ed PM |
71 | or a detailed low-level format for output |
72 | (the latter is for debugging purposes and has to be enabled | |
73 | in the source code) | |
74 | \item Write to standard output or to a file | |
75 | \item Insert a custom \osl{} header | |
b96bb723 | 76 | (see the specification of the \oslboth{} in Section~\ref{osl_spec} for details) |
c31df1ed PM |
77 | \item Consistency check against a custom \osl{} header |
78 | \item Consistency check against the standard \osl{} header without internet connection | |
79 | \item Act interactively or non-interactively | |
80 | \item Skip currently retrieved database (and try next on server), | |
81 | skip current server or abort the overall process at any time, even in | |
82 | non-interactive mode | |
83 | \item Define multiple database servers to check in order for the specified database | |
84 | \item Specify multiple bootstrapping operations to perform in order | |
85 | \item Configure the features described in the above notes | |
86 | per bootstrapping operation | |
87 | \item Display a help text describing the usage of \myprog{}, | |
88 | including the description of all command-line arguments | |
89 | \end{itemize} |