Skip to content
Snippets Groups Projects
Commit 59598bd6 authored by Andreas Schärtl's avatar Andreas Schärtl
Browse files

report: [x] implement Q2

parent a068ceac
No related branches found
No related tags found
No related merge requests found
......@@ -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
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment