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
GitLab community forum
Contribute to GitLab
Provide feedback
Terms and privacy
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
supervision
schaertl_andreas
Commits
aec98c24
Commit
aec98c24
authored
Sep 1, 2020
by
Andreas Schärtl
Browse files
Options
Downloads
Patches
Plain Diff
slides: work on implementation chapter
parent
256aefc8
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/slides/slides.tex
+26
-9
26 additions, 9 deletions
doc/slides/slides.tex
with
26 additions
and
9 deletions
doc/slides/slides.tex
+
26
−
9
View file @
aec98c24
...
@@ -130,8 +130,19 @@
...
@@ -130,8 +130,19 @@
\begin{frame}
{
Implementation: Versioning
}
\begin{frame}
{
Implementation: Versioning
}
\begin{itemize}
\begin{itemize}
\item
versioning is a pain in the ass
\item
One problem in our implementation is
\emph
{
versioning
}
.
\item
as a work-around we can re-create the dataset every time
\item
Data flows
\begin{align*}
\mathcal
{
L
}
\rightarrow
\mathcal
{
E
}
\rightarrow
\mathcal
{
D
}
\end{align*}
from
\emph
{
third party library~
$
\mathcal
{
L
}$}
to an
\emph
{
XML
representation~
$
\mathcal
{
E
}$}
to
\emph
{
database storage~
$
\mathcal
{
D
}$}
.
\item
When
$
\mathcal
{
E
}$
changes, so does~
$
\mathcal
{
E
}$
when a new
export is run. This should result in~
$
\mathcal
{
D
}$
changing as well.
\item
Difficult! A work around is re-creating databases from
scratch. Maybe the only realistic way to tackle this
problem. Maybe splitting up knowledge into many smaller
repositories is a good idea.
\end{itemize}
\end{itemize}
\end{frame}
\end{frame}
...
@@ -141,9 +152,13 @@
...
@@ -141,9 +152,13 @@
\begin{frame}
{
Applications and Questions
}
\begin{frame}
{
Applications and Questions
}
\begin{itemize}
\begin{itemize}
\item
implemented some queries and applications that might be
\item
Based on our implementation of Collecter, Importer and
interesting for tetrapodal search
Endpoint we implemented some applications and queries.
\item
did find out about some interesting questions
\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{itemize}
\end{frame}
\end{frame}
...
@@ -151,10 +166,12 @@
...
@@ -151,10 +166,12 @@
\begin{frame}
{
Applications and Questions: Used Predicates
}
\begin{frame}
{
Applications and Questions: Used Predicates
}
\begin{itemize}
\begin{itemize}
\item
hello world kind of application to query the kinds of
\item
As a
\emph
{
Hello World
}
application, we wrote an application
predicates in use
with RDF4J that looks at what ULO~predicates are used.
\item
only subsets of predicates are used; important for a
\item
Both Coq and Isabelle exports used less than a third of all
tetrapodal search implementors
ULO~predicates. Many predicates are used by neither exports.
\item
Queries formulated for a tetrapodal search system have to
account for these ``holes'' in existing data sets.
\end{itemize}
\end{itemize}
\end{frame}
\end{frame}
...
...
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