Newer
Older
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
% This file contains sections and paragraphs cut from the report.
% I'll delete them eventually, but for now I'd like to have them
% available for referencing.
\subsection{Kinds of Applications}
Storing information in RDF triplets allows for any kind of queries,
meaning it is not optimized for any kind of application. For the sake
of this project, we tried out three categories of applications.
\begin{itemize}
\item Of course the initial starting point for this project was
the idea of tetrapodal search. Our first application
\emph{ulosearch} tires to offer an easy way of searching in the
ULO/RDF data set.
\item With lots of data in a database, it appears attractive to
visualize the data set in some kind graphical way in the
\emph{ulovisualize} application.
\item Finally, we want to experiment a bit. The available ULO/RDF
data sets are about proofs and theorems and should include links
between. It might be interesting to find out which proofs and
definitions are more important than others such that we can
create a kind of ranking of them. This is explored in the
\emph{ulorate} application.
\end{itemize}
\subsection{Database Interface}
For integrating the ULO/RDF data set into an existing application, it
probably is reasonable to directly query the data set using RDF4J.
That is, of course, assuming the existing co debase is based on the
{JVM}. If that is not the case, generating SPARQL queries is the
obvious choice.
The advantage of this approach is that connecting and interacting
with the database is straightforward. The disadvantage is that this
approach requires a deep understanding of structure of the underlying
ULO triplets.
\subsection{A Language for Organizational Data}
ULO/RDF is a subset of RDF. While it can be queried as just standard
RDF data, maybe it is helpful to design a query language only for
ULO/RDF triplets. Expressions in this particular query language could
then be converted to SPARQL or RDF4J expressions. Ideally this means
that (1)~the query language is intuitive and easy to use for this
specific use case and (2)~execution is still fast as the underlying
SPARQL database is already very optimized.
% This does not really fit, in general this entire section is kind
% of a mess and contains more stuff about things that do not even
% exist yet than actual information.