report: applications: write about pre-computed scores

doc/report/applications.tex

@@ -157,6 +157,20 @@ do anyways. Either way, this is not so much an issue for the
 organizational storage engine and more one that a tetrapodal search
 aggregator has to account for.
 
+Another problem is that computing these scores can be quite time
+intensive. Even if calculating a score for one given object is fast,
+doing so for the whole data set might quickly turn into a problem.  In
+particular, if we wish to show the $n$~object with best scores, we do
+need to compute scores for all relevant triplets for that score. In
+\emph{ulo-storage}, all scores we experimented with were easy enough
+and the data sets small enough that that this did not become a
+concrete problem. But in a larger tetrapodal search system, caching or
+lazily or ahead of time computed results will probably we a
+necessity. Which component takes care of keeping this cache is not
+clear right now, but we advocate for keeping caches of previously
+computed scores separate from the core \emph{ulo-storage} Endpoint
+such that the Endpoint can be easily updated.
+
 \subsubsection{Categorizing Algorithms and Algorithmic Problems}
 
 The second query~$\mathcal{Q}_2$ we decided to focus on wants to