\subsubsection{Basic usage}
\label{basic}
Currently, the only user interface of \myprog{} is a command-line interface.
-Since the program is supposed to bootstrap the OBDA Specification automatically and
+Since the program is supposed to bootstrap the OBDA specification automatically and
thus there is little interaction, but a lot of output, this was considered ideal.
Basically, one invocation of \myprog{} will initiate the automatic, non-interactive
bootstrapping of exactly one \osl{} specification written to the standard output,
a behavior which can be modified via command-line arguments.
Because of its ability to write to the standard output (which is also the default
behavior), it is easy to pipe the output of \myprog{} directly into a program that
-handles it in a Unix-/POSIX-like fashion TODO:
+handles it in a Unix-/POSIX-like fashion \cite{unix}:
\codepar{db2osl myserver.org | osl2onto myserver.org}
(supposed \name{osl2onto} is a tool that reads an \osl{} specification from its
standard input and uses it to bootstrap an ontology from the database
specified on its command line).\\
-This scheme is known as ``filter-pattern'' TODO.
+This scheme is known as ``Pipes and Filters architectural pattern'' \cite{patterns}.
By inserting additional ``filters'', the bootstrapping process can be customized
without changing any of the involved programs:
\subsubsection{Configuration via command-line arguments}
The behavior of \myprog{} itself can be adjusted via command-line arguments (only).
-The syntax for their application follows the POSIX standard TODO.
+%The syntax for their application follows the POSIX standard \cite{posix} (no!).
Most features can be configured via short options (as, for example, \code{-P}).
To allow for enhanced readability of \myprog{} invocations, each feature can (also)
be configured via a long option (like \code{\textendash\textendash password}).
while not addressing any real difficulties.
The command-line arguments \myprog{} currently supports are
-described in table \ref{if_tbl_arguments_desc},
+described in table \ref{if_tbl_arguments_desc};
their default values are listed in table \ref{if_tbl_arguments_def}.
There is currently no switch to set the output format, since the only supported
output format, besides \osl{}, is a low-level output format for debugging purposes.
in the example) will have no effect on other operations.
This ensures that typical errors are prevented when merging several invocations
of \myprog{} into one (or vice versa)
-and allows for a straight-forward, comprehensive and clean implementation.
+and allows for a straight-forward and comprehensive implementation.
\subsubsection{Advanced modifications}
Since \osl{} specifications are plain text files, a user can edit them in any desired
text editor if he wants to change them in ways that go beyond the functionality
\myprog{} provides or that can be achieved by scripts or programs modifying their
input automatically.
-Because of \osl{} being defined to be a subset of \name{OWL} (see the specification
-of \osl{} in section \ref{oslspec}), he can thereby take advantage of editors
+Because of \osl{} being a subset of \name{OWL} (see the specification
+of \osl{} in section \ref{osl_spec}), he can thereby take advantage of editors
supporting syntax highlighting or other features making the handling of
the respective \name{OWL} serialization more comfortable.
Doing so, care has to be taken to make the ontology remain a conforming \osl{}
specification. However, since the restrictions imposed by \osl{} are rather
small and intuitive, this is easily achieved.
-Furthermore, upcoming tools supporting \osl{} (see section \fullref{future}) are very
-likely to be able to check their input for conformity with the \osl{} definition.
+Furthermore, upcoming tools supporting \osl{} (see section \fullref{future}) most
+likely will be able to check input files for conformity with the \osl{} definition.
\subsection{Integration into systems}
Besides the use cases described in section ``\nameref{basic}'',
re-bootstrapping necessary:
\codepar{db2osl -d mydb myserver.org | sha256sum >oldsum\\
cp oldsum newsum\\
- while diff oldsum newsum; do\\
+ while diff oldsum newsum; do\ \ \# while checksums are the same\\
\ind sleep 3600\ \ \# wait 1 hour\\
\ind db2osl -d mydb myserver.org | sha256sum >newsum\\
done\\
rm oldsum newsum\\
\# notify web admin via e-mail:\\
- mutt -s "Re-bootstrapping necessary" web-admin@myserver.org}
+ date | mutt -s "Re-bootstrapping necessary" web-admin@myserver.org}
Another possible example is the integration of \myprog{} into a shell script
that bootstraps all databases on a server:
Since the programming language used to implement \myprog{} is \name{Java},
it is possible to deploy it on all platforms offering the
-\name{Java Runtime Environment} TODO.
+\name{Java} Runtime Environment TODO.
Additionally, it is possible to deploy it as a Web application TODO.
To simplify integration on the code level, the architecture of \myprog{} was
this of course has to be implemented.
If not, it is sufficient to replace the used \code{Logger} object by anohter one
providing the desired behavior, since the \code{Logger} class is part of the
-\name{Java} API and widely used TODO.
+\name{Java} API and widely used \cite{log}.
This is a good example of how using well-known and commonly used classes can
greatly improve modularity and reusability.
git://git.uio.no / u / philim / db2osl_thesis.git / blobdiff