report: rename triplet store -> triple store

doc/report/conclusion.tex

@@ -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

doc/report/implementation.tex

@@ -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} triplet 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, triplet 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 triplet 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 triplet 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
-      triplet 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 triplet 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