Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
S
schaertl_andreas
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Container registry
Model registry
Operate
Environments
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Terms and privacy
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
supervision
schaertl_andreas
Commits
59598bd6
Commit
59598bd6
authored
4 years ago
by
Andreas Schärtl
Browse files
Options
Downloads
Patches
Plain Diff
report: [x] implement Q2
parent
a068ceac
No related branches found
No related tags found
No related merge requests found
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
doc/report/applications.tex
+28
-19
28 additions, 19 deletions
doc/report/applications.tex
with
28 additions
and
19 deletions
doc/report/applications.tex
+
28
−
19
View file @
59598bd6
...
...
@@ -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
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment