review conclusion

doc/report/conclusion.tex

@@ -33,8 +33,7 @@ difficult. \emph{ulo-storage} circumvents this problem by re-creating
 the GraphDB data set in regular intervals.  Indeed it might be
 difficult to find an efficient alternative. Tagging each triplet with
 some version number doubles the number of triplets that need to be
-stored and will undoubtedly makes imports in the database more
-costly. Re-creating the index and maybe splitting up the knowledge
+stored. Re-creating the index and maybe splitting up the knowledge
 base into smaller easier to update sub-repositories looks like the
 most promising approach for now.
 
@@ -47,12 +46,11 @@ back. This shows the difficulty of designing an ontology that is both
 concise and expressive. But while it is all good and well to recommend
 writers of exports to use the full set of predicates, it might simply
 not make sense to use the full set for a given third party library. We
-think that it is a bit too early to argue for the removal of
-particular predicates, rather it might be better to look at future
-export projects and then evaluate which predicates are used and which
-are not.
+think that it is too early to argue for the removal of particular
+predicates, rather it is better to look at future export projects and
+then evaluate which predicates are in use and which are not.
 
-Despite these many open questions, \emph{ulo-storage} provides the
-necessary infrastructure for importing ULO triplets into an efficient
-storage engine. A necessary building block for a larger tetrapodal
-search system.
+Despite many open questions, \emph{ulo-storage} provides the necessary
+infrastructure for importing ULO triplets into an efficient storage
+engine. A necessary building block for a larger tetrapodal search
+system.