fix the location of the footnotes

Author: constraintAutomaton

section/result.tex

@@ -29,7 +29,7 @@ \section{Preliminary Results}
 
 An open-source implementation of the \href{https://github.com/constraintAutomaton/query-shape-detection}{algorithm} and an 
 \href{https://github.com/constraintAutomaton/comunica-feature-link-traversal/tree/feature/shapeIndex}{integration} in the query engine 
-Comunica \cite{taelman_iswc_resources_comunica_2018} is available online~\sepfootnote{fn:impl}.
+Comunica \cite{taelman_iswc_resources_comunica_2018} is available online.~\sepfootnote{fn:impl}
 We use the \href{https://github.com/SolidBench/SolidBench.js}{benchmark Solidbench} \cite{Taelman2023} to compare our approach with the current state-of-the-art (the \href{https://solid.github.io/type-indexes/}{type index} and the \href{https://www.w3.org/TR/ldp/}{LDP specification}~\sepfootnote{fn:ldp} as structural assumptions)~\cite{Taelman2023}.
 We used the supported subset of SolidBench queries, skipping the currently unimplemented \href{https://www.w3.org/TR/sparql11-query/#propertypaths}{SPARQL property paths}~\sepfootnote{fn:propertyPath} and unions.
 We executed each query 50 times with a timeout of 1 minute (6,000 ms).

section/shape_index.tex

@@ -31,11 +31,11 @@ \section{Shape Index and Query-Shape Containment}
 
 \subsection{Shape Index}
 
-Our method introduces the concept of a \emph{shape index} to reduce query execution time by minimizing unnecessary dereferencing of RDF documents within web subdomains (sets of URLs or URL patterns)~\sepfootnote{fn:domain}.
+Our method introduces the concept of a \emph{shape index} to reduce query execution time by minimizing unnecessary dereferencing of RDF documents within web subdomains (sets of URLs or URL patterns).~\sepfootnote{fn:domain}
 We define a shape index as a set of mappings between RDF data shapes and sets of resources.
 This mapping concept shares similarities with shape mapping~\cite{Gayo2018} and target declarations~\cite{Gayo2018Shacl}.
 However, instead of mapping shapes to RDF subgraphs, the shape index maps shapes to sets of documents.
-The shape index also shares commonalities with \href{https://shapetrees.org/}{shape trees}~\sepfootnote{fn:shapetrees}, however, it is designed to be a simpler formulation focused on query optimization.
+The shape index also shares commonalities with \href{https://shapetrees.org/}{shape trees},~\sepfootnote{fn:shapetrees} however, it is designed to be a simpler formulation focused on query optimization.
 The shape index has a range of applications defined in a domain and a flag indicating if the index is \emph{complete}.
 A shape index is complete when every resource in the domain is associated with a shape within the shape index.
 In a shape index when a shape is mapped to a set of RDF resources then the shape \emph{must} validate those resources.
@@ -52,7 +52,7 @@ \subsection{Query-Shape Containment}
 and not suffer from the associated longer execution time during the traversal of environments containing a shape index.
 The source selection process is schematized for a single (sub)domain in Figure~\ref{fig:shape_index}.
 The process starts with the discovery of the shape index in the current (sub)domain.
-In the case of Solid, the index can be at the root of the pod to be easily discoverable~\sepfootnote{fn:solidPrivacy}.
+In the case of Solid, the index can be at the root of the pod to be easily discoverable.~\sepfootnote{fn:solidPrivacy}
 After the dereferencing of the index, the analysis is started inside the query engine.
 The analysis consists of interpreting the binding results (homomorphism and "partial" homomorphism) of the \emph{query-shape containment} problem.
 The algorithm divides the query from the user into multiple star patterns with their dependent star pattern ($Q_{star}$).
@@ -64,7 +64,7 @@ \subsection{Query-Shape Containment}
 In a similar case with an \emph{incomplete} shape index, the query engine can only use the shape index for data discovery.
 This case is similar to the usage of the type index but with a more reaching ability to match a query with the index because shapes in their definition describe the properties (RDF predicates) of the entities whereas the type index only provides the classes IRIs.
 It is possible to dereference the class IRIs to get information about the properties (if available), however, it is not the current practice \cite{Taelman2023}.
-A comparison of the RDF data shapes and RDF class approach due to their potential similarities is delegated to future works~\sepfootnote{fn:litShapeComparaison}.
+A comparison of the RDF data shapes and RDF class approach due to their potential similarities is delegated to future works.~\sepfootnote{fn:litShapeComparaison}
 
 \subsection{A Concrete Example}
 
@@ -76,7 +76,7 @@ \subsection{A Concrete Example}
 When traversing the network the query engine cannot know the content of the documents encountered, therefore, the engine \emph{must} deference every reachable document as defined by a reachability criterion.
 The presence of a shape index can change the state of affairs.
 If the engine encounters a domain containing exclusively book data as indicated by a complete shape index, the engine can skip the documents of the domain. 
-Conversely, if a domain has comment and movie review data declared by a complete shape index, the query engine can safely limit its dereferencing operations to the set of documents related to comments without affecting results completeness.
+If a domain has comment and movie review data declared by a complete shape index, the query engine can safely limit its dereferencing operations to the set of documents related to comments without affecting results completeness.
 The engine can restrict its dereferencing operations because at least one star pattern is contained in the comment shape and none in the movie review and book shapes.
 If the engine encounters a domain regardless of the completeness of the index, declaring comment, forum, and individual (moderators are individuals/people) data, among others, then the documents associated with the non-query-relevant part of the domain can be ignored with the same containment logic presented earlier.
 Thus, we can consider that the traversal proceeds domain by domain ignoring documents known a priori to not content query-relevant data.