diff --git a/doc/report/implementation.tex b/doc/report/implementation.tex
index 04476ccb36c5faac55b2de9658ca017926e45252..12a6ab3a4e87b326e42204eaacf43c8a47f375be 100644
--- a/doc/report/implementation.tex
+++ b/doc/report/implementation.tex
@@ -1,13 +1,17 @@
 \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}