diff --git a/sections/feasibility.tex b/sections/feasibility.tex
index 86e6ff7f7abf2fffb7aaee0201836bd6ba29775e..0ce23d020a1af462c203fd2ffc0d96e5d8f4d687 100644
--- a/sections/feasibility.tex
+++ b/sections/feasibility.tex
@@ -11,7 +11,7 @@ RQ1 RQ2
 - different additions:
   - inference
   - test model
-- this can be solved with the RAG tool presented in \cref{chap:RAGO}
+- this can be solved with the RAG tool presented in \cref{chap:rago}
 - in \cref{sec:inf} we show how inference can be done
 - \cite{ttc-rag-von-ceur} for test model/model connections
   - http://ceur-ws.org/Vol-2310/ A JastAdd- and ILP-based Solution to the Software-Selection and Hardware-Mapping-Problem at the TTC 2018
diff --git a/sections/introduction.tex b/sections/introduction.tex
index 8d41505929f7dfc7b4c08f89ce7751ba1b403c83..7fb3173dbca1cbfa6d9f4d65fa4a9b5fc37a29ec 100644
--- a/sections/introduction.tex
+++ b/sections/introduction.tex
@@ -4,11 +4,11 @@ Also, it might be a meaningful approach to raise the security and quality in web
 
 % example with [2]
 One kind of testing such architectures is to validate REST interfaces and check if there are errors in them. \\
-In the last years, the OpenAPI Specification has become the common way to document the communication endpoints and exchanged data structures [1]. This is useful to test REST interfaces, because it enables the black-box testing approach.
+In the last years, the OpenAPI Specification\footnote{\url{https://swagger.io/specification}} has become the common way to document the communication endpoints and exchanged data structures. This is useful to test REST interfaces, because it enables the black-box testing approach.
 OpenAPI specifications are described as JSON or YAML documents and are defined by a semi-formal specification describing permitted and required elements as well as their semantics. While there is no formal definition of the full OpenAPI language, a meta-schema exists for the JSON Schema parts of the language.
 
 % abstract 
-This paper investigates how such specifications can be used to test interfaces described by them. Since these specifications itself are tree-shaped, the investigation focuses on a grammar-based analysis approach, reference attribute grammars (RAGs). 
+This paper investigates how such specifications can be used to test interfaces described by them. Since these specifications are tree-shaped, the investigation focuses on a grammar-based analysis approach, reference attribute grammars (RAGs). 
 This paper also compares already presented REST API automatic testing approaches and examines whether these can also be implemented in RAGs, whether this implementation makes sense at all and whether RAG improves at implementing REST API automated testing. \\
 To sum up, following three questions are formulated as research questions:
 
diff --git a/sections/stm1.tex b/sections/stm1.tex
index 6c755193d9f5f1390ebcfba66ae1b4a61553a5ba..fb070e97b4a0c9635d5473ac7751ec58db420f5b 100644
--- a/sections/stm1.tex
+++ b/sections/stm1.tex
@@ -1,7 +1,7 @@
 \section{Random Testing}
 
-OpenAPI defines a parameter in an operation in four types, Query, Path, Header and Cookie$^{5}$. \footnote{this is described at \url{http://test.com}} In this work, only Query and Path parameters are considered to research the functionality of the Fuzzing prototype in RAG. These parameters are clearly describable in String values and also comfortably testable, because they target only variable URIs. \\
-For the experiments, the OpenAPI document of a Pet Store is mainly used$^{6}$. Additionally, only GET and POST operations are tested to research basic functionality firstly.
+OpenAPI defines a parameter in an operation in four types, Query, Path, Header and Cookie\footnote{\url{https://swagger.io/docs/specification/describing-parameters}}. In this work, only Query and Path parameters are considered to research the functionality of the Fuzzing prototype in RAG. These parameters are clearly describable in String values and also comfortably testable, because they target only variable URIs. \\
+For the experiments, the OpenAPI document of a Pet Store is mainly used\footnote{\url{https://petstore.swagger.io}}. Additionally, only GET and POST operations are tested to research basic functionality firstly.
 
 % Process
 The main code at random testing is following:
@@ -23,14 +23,5 @@ with the generated URI (Line 9).
 % Result
 Besides operations with requirements of request bodies, results of this implementation made possible to observe that parameters based on the specification were successfully randomized and they produced documented status codes in their operations. For future work, constraints of schema (minItems, maxItems, minLengths, maxLengths, etc.) can be completely extended. In this approach, the generator considers only the existence of enums.
 
-\begin{comment}
--  Type of Parameters: Path,Query, Header\\
--  Only Path,Query\\
--  Reasons of selecting only path, query\\
--  Process\\
--  Results\\
-\end{comment}
-
-
 % ^5 : https://swagger.io/docs/specification/describing-parameters/
 % ^6 : https://petstore.swagger.io
\ No newline at end of file
diff --git a/thesis.tex b/thesis.tex
index 27b890b5904dbff7ceb7d96cec23497c86e04797..f2aecc91619433d530aac6e8b6c8bced3dfd7467 100644
--- a/thesis.tex
+++ b/thesis.tex
@@ -133,7 +133,7 @@
 \input{sections/conclusion}
 
 
-%\printbibliography[heading=bibintoc]\label{sec:bibliography}%
+\printbibliography[heading=bibintoc]\label{sec:bibliography}
 
 %\appendix
 %\input{sections/appendix}