report: [x] implement Q2

doc/report/applications.tex

@@ -83,27 +83,36 @@ proof of concept implementations.
     problems with a given property (runtime complexity). We need
     to consider where each of these three components might be stored.
 
-    First, let us consider algorithms. Algorithms can be formulated as
-    computer code which should be accessible from storage for symbolic
-    knowledge. But this encodes just the algorithm itself, not what
-    the algorithm is for and nor is it possible to quickly evaluate
-    properties such as $NP$~completeness for querying. They need to be
+    \textbf{Symbolic Aspect} First, let us consider
+    algorithms. Algorithms can be formulated as computer code which
+    should be accessible from storage for symbolic knowledge. But
+    symbolic knowledge encodes just the algorithm itself, not what the
+    algorithm is for nor is it possible to quickly evaluate properties
+    such as $NP$~completeness for querying. Such meta data needs to be
     stored in a separate index.
 
-    It seems that what an algorithm implements and with which
-    properties is a case of organizational knowledge. With ULO, we
-    could search for an algorithm identified by a \texttt{ulo:name},
-    but that leaves much to be desired. Maybe what is missing in
-    ULO/RDF is a way to define ``problems~$\phi$'', e.g.\ the
-    traveling salesman problem, and a way of expressing that a given
-    object ``computes~$\phi$''. With problem~$\phi$ we could associate
-    theorems such as ``$\phi$ is in $NP$''.
-
-    At this point it appears that our ULO/RDF data sets can not help
-    us with answering query~$\mathcal{Q}_{2}$. It remains a topic
-    for discussion whether support for algorithms should be added
-    to the upper level ontology or whether such concepts should be
-    built on top of the existing predicates.
+    \textbf{Organizational Aspect} The purpose of a given algorithm
+    (what problem it solves) as well as meta properties such as time
+    and space complexity needs to be stored in a separate index. For
+    this to be easy to look up, we propose to file this meta
+    information as organizational knowledge. It certainly isn't easily
+    searchable from symbolic or narrative knowledge and nor is it
+    concrete knowledge as we are talking about general properties of
+    algorithms.
+
+    While ULO has a concept of \texttt{ulo:theorem}
+    and \texttt{ulo:proof}, there is no native way to represent
+    (a)~problems (e.g.\ the traveling salesman problem) and
+    (b)~algorithms that compute a given problem. If ULO had such a
+    concept, we could then introduce new data predicates that tell us
+    something about the properties of problems and
+    algorithms. Organized in such a schema, query~$\mathcal{Q}_{2}$
+    would be easy to service.
+
+    Of course the question here is whether adding another first level
+    concept to ULO is a good idea or whether it would be better to
+    think of another ontology for algorithms. We leave this for later
+    discussion.
 
     \item \textbf{$\mathcal{Q}_{3}$ ``Find integer sequences whose generating
     function is a rational polynomial in $\sin(x)$ that has a Maple