diff --git a/doc/report/endpoints.tex b/doc/report/endpoints.tex
index 8fe03e5726260e85d6b1b8df09be27084cd79780..014e9d10d90db48d9e9319ba31ffbe62cb9d3979 100644
--- a/doc/report/endpoints.tex
+++ b/doc/report/endpoints.tex
@@ -7,16 +7,17 @@ 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 implemented by various vendors. Both
-approaches have unique advantages.
+on the RDF4J Java library. Both approaches have unique advantages.
 
-\begin{description}
-    \item[SPARQL] is a standardized query language for RDF triplet
+\begin{itemize}
+      \item SPARQL is a standardized query language for RDF triplet
       data~\cite{sparql}. The specification includes not just syntax
       and semantics of the language itself, but also a standardized
-      REST interface for querying databases.
+      REST interface for querying database servers.
 
       \textbf{Syntax} SPARQL is inspired by SQL and as such the
       \texttt{SELECT} \texttt{WHERE} syntax should be familiar to many
@@ -37,10 +38,11 @@ approaches have unique advantages.
       querying triplet stores, lots of literature and documentation is
       available~\cite{sparqlbook, sparqlimpls, gosparql}.
 
-    \item[RDF4J] is a Java API for interacting with triplet stores,
-      implemented based on a superset of the {SPARQL} REST interface~\cite{rdf4j}.
-      GraphDB supports RDF4J, in fact it is the recommended way of
-      interacting with GraphDB repositories~\cite{graphdbapi}.
+      \item RDF4J is a Java API for interacting with triplet stores,
+      implemented based on a superset of the {SPARQL} REST
+      interface~\cite{rdf4j}.  GraphDB is one of the database
+      servers that supports RDF4J, in fact it is the recommended way
+      of interacting with GraphDB repositories~\cite{graphdbapi}.
 
       \textbf{Syntax} Instead of formulating textual queries, RDF4J
       allows developers to query a repository by calling Java API
@@ -59,12 +61,14 @@ approaches have unique advantages.
       the JVM and its languages. But in practice, we found RDF4J to be
       quite convenient, especially for simple queries, as it allows us
       to formulate everything in a single programming language rather
-      than mixing languages and awkward string literals.
+      than mixing programming language with awkward query strings.
 
       We also found it quite helpful to generate Java classes from
       OWL ontologies that contain all definitions of the ontology and
       make it readable by any IDE~\cite{rdf4jgen}.
-\end{description}
+\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,