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
9a6e7639
Commit
9a6e7639
authored
4 years ago
by
Andreas Schärtl
Browse files
Options
Downloads
Patches
Plain Diff
report: rename triplet store -> triple store
parent
3ecf7300
No related branches found
Branches containing commit
No related tags found
No related merge requests found
Changes
2
Hide whitespace changes
Inline
Side-by-side
Showing
2 changed files
doc/report/conclusion.tex
+1
-1
1 addition, 1 deletion
doc/report/conclusion.tex
doc/report/implementation.tex
+6
-6
6 additions, 6 deletions
doc/report/implementation.tex
with
7 additions
and
7 deletions
doc/report/conclusion.tex
+
1
−
1
View file @
9a6e7639
...
...
@@ -25,7 +25,7 @@ into the database, the imported data is thoroughly checked and mistakes
are reported right away. Bugs in exporters that produce faulty XML
would be found earlier in development.
The second problem is that of versioning triplets in the GraphDB
The second problem is that of versioning triplets in the GraphDB
triple
store. While adding new triplets to an existing GraphDB store is not
a problem, updating existing triplets is difficult.
\emph
{
ulo-storage
}
solves this by simply re-creating the GraphDB data set in regular
...
...
This diff is collapsed.
Click to expand it.
doc/report/implementation.tex
+
6
−
6
View file @
9a6e7639
...
...
@@ -30,7 +30,7 @@ the flow of data.
\item
With streams of ULO files assembled by the Collector, this
data then gets passed to an
\emph
{
Importer
}
. An Importer uploads
RDF~streams into some kind of permanent storage. As we will see,
the GraphDB~
\cite
{
graphdb
}
triple
t
store was a natural fit.
the GraphDB~
\cite
{
graphdb
}
triple store was a natural fit.
\item
Finally, with all triplets stored in a database, an
\emph
{
Endpoint
}
is where applications access the underlying
...
...
@@ -94,7 +94,7 @@ straight-forward, our software only needs to upload the RDF file
stream as-is to an HTTP endpoint provided by our GraphDB instance.
\emph
{
(
{
TODO
}
: Write down a small comparison of different database
types, triple
t
stores and implementations. Honestly the main
types, triple stores and implementations. Honestly the main
advantage of GraphDB is that it's easy to set up and import to;
maybe I'll also write an Importer for another DB to show that the
choice of database is not that important.)
}
...
...
@@ -138,14 +138,14 @@ anymore.
\subsection
{
Endpoints
}
\label
{
sec:endpoints
}
With ULO triplets imported into the GraphDB triple
t
store by Collector
With ULO triplets imported into the GraphDB triple store by Collector
and Importer, we now have all data available necessary for querying.
As discussed before, querying from applications happens through an
Endpoint that exposes some kind of
{
API
}
. The interesting question
here is probably not so much the implementation of the endpoint itself,
rather it is the choice of API than can make or break such a project.
There are multiple approaches to querying the GraphDB triple
t
store,
There are multiple approaches to querying the GraphDB triple store,
one based around the standardized SPARQL query language and the other
on the RDF4J Java library. Both approaches have unique advantages.
...
...
@@ -171,10 +171,10 @@ on the RDF4J Java library. Both approaches have unique advantages.
\textbf
{
Advantage
}
Probably the biggest advantage is that SPARQL
is ubiquitous. As it is the de facto standard for querying
triple
t
stores, lots of implementations and documentation are
triple stores, lots of implementations and documentation are
available~
\cite
{
sparqlbook, sparqlimpls, gosparql
}
.
\item
RDF4J is a Java API for interacting with triple
t
stores,
\item
RDF4J is a Java API for interacting with triple stores,
implemented based on a superset of the
{
SPARQL
}
REST
interface~
\cite
{
rdf4j
}
. GraphDB is one of the database
servers that supports RDF4J, in fact it is the recommended way
...
...
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