report: remove two queries

We are cutting away sample queries which do not add any insight. They
are slightly different but lead to similar conclusions. So it's better
to just have one.

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}