@@ -214,7 +214,7 @@ The class \emph{ShexValidationRecord} stores the result of the validation for ev
\subsection{Front-end}
\label{frontend}
We implemented a front-end where the user can choose a \emph{knowledge graph} as well as a type of knowledge graph and its type. \todo{check whether this is what we are doing in the finished version} In addition, the user can also set a limit on the number of nodes of the specified type that they wish to have constraints generated for. \todo{maybe also put this explanation in the query section} As output, \emph{ShEx} constraints as well as a validation of the subgraph against those constraints are returned. The constraints can be edited by the user and the selected subgraph can be re-validated against the newly edited constraints.
We implemented a front-end where the user can choose a \emph{knowledge graph} as well as a type of knowledge graph and its type. \todo{check whether this is what we are doing in the finished version} In addition, the user can also set a limit on the number of nodes of the specified type that they wish to have constraints generated for. \Valerian{See Figure \ref{fig:frontend} for how it looks.}\todo{maybe also put this explanation in the query section} As output\Valerian{(see Figure \ref{fig:frontend_shex})}, \emph{ShEx} constraints as well as a validation of the subgraph against those constraints are returned. The constraints can be edited by the user and the selected subgraph can be re-validated against the newly edited constraints.
If a node is deemed invalid, a reason is given, e.g. "Cardinality violation (min=1): 0". The user can download the subgraph that was validated. The interaction between user, front-end and server can also be seen in Fig.~\ref{fig:sequence}.
\todo{explain how different limit influences data output}
...
...
@@ -226,13 +226,6 @@ If a node is deemed invalid, a reason is given, e.g. "Cardinality violation (min