Skip to content
Snippets Groups Projects
Commit a18ecfb6 authored by Andreas Schärtl's avatar Andreas Schärtl
Browse files

report: implementation: set up ground work for subsections

I want one subsection for each component.
parent 330768f1
No related branches found
No related tags found
No related merge requests found
\section{Implementation}\label{sec:implementation}
One of the two contributions of \emph{ulo-storage} is that we
implemented components for making organizational mathematical
knowledge queryable. This section first makes out the individual
required component for this tasks and then describes some details
of the actual implementation for this project.
\subsection{Components Implemented for \emph{ulo-storage}}\label{sec:components}
With RDF files exported and available for download as Git repositories
on MathHub, we have the goal of making the underlying data available
for use in applications. It makes sense to first identify the various
components that might be involved in such a system.
Figure~\ref{fig:components} illustrates all components and their
relationships.
for use in applications. Figure~\ref{fig:components} illustrates the
implemented components and their relationships.
\begin{figure}[]\begin{center}
\includegraphics{figs/components}
......@@ -44,10 +48,17 @@ relationships.
\end{itemize}
Collecter, Importer and Endpoint provide us with an easy and automated
way of making RDF files ready for use with applications. In this
introduction we only wanted to give the reader a general understanding
in the infrastructure that makes up \emph{ulo-storage}, the following
sections will explain each component in more detail.
way of making RDF files ready for use with applications. We will now
take a look at the actual implementation created for
\emph{ulo-storage}.
\subsection{Collecter}\label{sec:collecter}
\emph{here be dragons}
\subsection{Importer}\label{sec:importer}
\emph{here be dragons}
\subsection{Endpoints}\label{sec:endpoints}
......@@ -58,8 +69,6 @@ Endpoint that exposes some kind of {API}. The interesting question
here is probably not so much the implementation of the endpoint itself,
rather it is the choice of API than can make or break such a project.
\subsection{Supported Endpoints}
There are multiple approaches to querying the GraphDB triplet store,
one based around the standardized SPARQL query language and the other
on the RDF4J Java library. Both approaches have unique advantages.
......@@ -119,11 +128,13 @@ on the RDF4J Java library. Both approaches have unique advantages.
make it readable by any IDE~\cite{rdf4jgen}.
\end{itemize}
\subsection{Recommendation}
We see that both SPARQL and RDF4J have unique advantages. While SPARQL
is an official W3C standard and implemented by more database systems,
RDF4J can be more convenient when dealing with JVM-based code bases.
For \emph{ulo-storage}, we played around with both interfaces and
chose whatever seemed more convenient at the moment. We recommend any
implementors to do the same.
\subsection{Deployment}
\emph{here be dragons}
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment