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