slides: fix typos

doc/slides/slides.tex

@@ -175,19 +175,7 @@
     \item Based on our implementation of Collecter, Importer and
       Endpoint we implemented some applications and queries.
     \item Our endpoint supports both SPARQL~\cite{sparql} and
-      RDF4j~\cite{rdf4j}. Both have their advantages.
-    \item While the applications themselves are not terribly
-      interesting, they lead us to some interesting questions. This
-      will be the focus of this discussion.
-  \end{itemize}
-\end{frame}
-
-\begin{frame}{Applications and Questions}
-  \begin{itemize}
-    \item Based on our implementation of Collecter, Importer and
-      Endpoint we implemented some applications and queries.
-    \item Our endpoint supports both SPARQL~\cite{sparql} and
-      RDF4j~\cite{rdf4j}. Both have their advantages.
+      RDF4J~\cite{rdf4j}. Both have their advantages.
     \item While the applications themselves are not terribly
       interesting, they lead us to some interesting questions. This
       will be the focus of this discussion.
@@ -287,16 +275,18 @@
     \item Importing existing XML~exports into a queryable database is
       pretty straightforward. It does introduce some interesting
       questions.
-    \item \emph{Versioning} of data sets requires us to re-create
+    \item Versioning of data sets requires us to re-create
       databases. This does introduce latency but is probably the only
       way out as diffing huge data sets is not feasible.
     \item Existing exports have ``holes'', they only use small-ish
       subsets of~{ULO}. On the other hand, representing algorithms and
       algorithmic problems might require us to extend~{ULO}? Maybe instead
       of tetrapodal search we need $n$-podal search.
+    \begin{itemize}
       \item Maybe it would be interesting to collect a database of
         algorithms and proofs (OEIS~\cite{oeis} for algorithms).
     \end{itemize}
+  \end{itemize}
 \end{frame}
 
 % [References]