diff --git a/doc/report/applications.tex b/doc/report/applications.tex
index b22a954bb4e0c0c4c2e29a0e71366c44083f4d57..1af30c10545eb41d99ea221b3d0acc4b4b7ae918 100644
--- a/doc/report/applications.tex
+++ b/doc/report/applications.tex
@@ -196,52 +196,7 @@ implementations.
     dcowl}) and keeping concepts separate is not entirely
     unattractive in itself.
 
-    \item \textbf{$\mathcal{Q}_3$ ``Find integer sequences whose
-    generating function is a rational polynomial in $\sin(x)$ that has
-    a Maple implementation not not affected by the bug in
-    module~$x$.''} We see that this query is about finding specific
-    instances, integer sequences, with some property.  This is a case
-    where information would be split between many sources.  The name
-    of the sequences is part of the organizational data set, the
-    generating function is part of symbolic knowledge, the Maple
-    implementation could be part of concrete knowledge.
-
-    \textbf{Organizational Aspect} Handling this query would probably
-    start by filtering for all integer sequences. It is not clear how
-    this should be achieved with ULO/RDF as it contains no unified
-    concept of a sequence.  It might be possible to take advantage
-    of \texttt{aligned-with} or some similar concept to find all such
-    sequences~\cite{align}. If this succeeds, an ULO index can provide the first
-    step in servicing this query. Here we are in a similar situation
-    as with~$\mathcal{Q}_2$. It is not clear whether we should
-    represent the idea behind ``integer sequences'' as a native
-    component of ULO or as something building on top of what ULO
-    provides.
-
-    As for the next steps, finding concrete algorithms and in
-    particular looking inside of them is not organizational data and
-    other indices will need to be queried. That said, it is an open
-    question whether ULO should contain more information (e.g.\ about
-    properties of the generating function) or whether such information
-    can be deduced from symbolic knowledge.
-
-    \item \textbf{$\mathcal{Q}_4$ ``CAS implementation of Gröbner bases that
-    conform to a definition in AFP.''} Gröbner Bases are a field of
-    study in mathematics particular attractive for use in computer
-    algebra systems (CAS)~\cite{groebner}. This query is asking for
-    concrete implementations of Gröbner Bases that match the definition
-    in the Archive of Formal Proofs~(AFP)~\cite{afp}.
-
-    We do have ULO/RDF exports for the AFP~\cite{uloisabelle}. Stated
-    like this, we can probably assume that $\mathcal{Q}_4$ is a query
-    for a very specific definition, identified by an ULO {URI}. No smart
-    queries necessary. What is missing is the set of implementations,
-    that is symbolic knowledge about actual implementations, and a way
-    of matching this symbolic knowledge with the definition in
-    {AFP}. While surely an interesting problem, it is not a task for
-    organizational knowledge.
-
-    \item \textbf{$\mathcal{Q}_5$ ``All areas of math that {Nicolas G.\
+    \item \textbf{$\mathcal{Q}_3$ ``All areas of math that {Nicolas G.\
     de Bruijn} has worked in and his main contributions.''}  This query
     is asking by works of a given author~$A$.  It also ask for their
     main contributions, e.g.\ what paragraphs or code~$A$ has authored.
@@ -256,7 +211,7 @@ implementations.
     first working version, the exports managed by \emph{ulo-storage}
     are enough to service this query.
 
-    As~$\mathcal{Q}_5$ is also asking for the main contributions
+    As~$\mathcal{Q}_3$ is also asking for the main contributions
     of~$A$, that is those works that~$A$ authored that are the most
     important. Importance is a quality measure, simply sorting the
     result by number of references might be a good start. Again, this
@@ -292,7 +247,7 @@ implementations.
     GROUP BY ?work
     ORDER BY DESC(?refcount)
     \end{lstlisting}
-    We see that we can formulate the idea behind~$\mathcal{Q}_5$ with
+    We see that we can formulate the idea behind~$\mathcal{Q}_3$ with
     one not very complicated SPARQL query. Because here everything is
     handled by the database access should be quick.
 \end{itemize}