Respond to feedback from Marjolein Verkouter

contents/2-vision.tex

@@ -44,13 +44,13 @@ This relationship between \pgls{ESAP} and the capabilities exposed by the other
 By design, \pgls{ESAP} is extensible: rather than attempting to anticipate every possible type of data repository, software, compute system, or other service provider, the platform provides generic interfaces through which it can be extended to encompass new functionality.
 
 In short, our approach is not to attempt to provide a single, integrated platform to which all researchers must adapt, but rather a set of functionalities from which various communities and research infrastructures can assemble an analysis platform geared to their specific needs.
-Deploying such a science platform provides at the scale of a system like \pgls{EOSC} provides a natural opportunity to integrate with the data and computing fabric this environment encompasses while simultaneously accessing the tools, techniques, and expertise other research domains bring to that environment.
+Deploying such a science platform at the scale of a system like \pgls{EOSC} provides a natural opportunity to integrate with the data and computing fabric this environment encompasses while simultaneously accessing the tools, techniques, and expertise other research domains bring to that environment.
 At the same time, we expect that instances of \pgls{ESAP} may usefully be deployed in other contexts, from providing services to just a few users within a small project, to supporting major pieces of infrastructure; it must therefore be capable of operating effectively at a range of scales.
 
 \subsection{Conceptual Model}
 \label{sec:vision:model}
 
-\pgls{ESAP}, in and of itself, provides no compute or analysis capabilities (beyond a simple ability to view tabular data and preview images).
+\pgls{ESAP}, in and of itself, provides no compute or analysis capabilities beyond a simple ability to view tabular data and preview images.
 Rather, it acts as a broker between users and the various query and analysis services which are available to them.
 These might include, for example:
 
@@ -137,7 +137,7 @@ Note that the basket is not generally expected to contain a complete representat
 
 Services integrated with the \pgls{ESAP} system are able to edit, augment, and update the contents of the users' shopping basket.
 
-This shopping basket metaphor extends include services --- such as \gls{IDA} or batch compute facilities --- and workflows from the \pgls{OSSR} and other repositories: as they move through the system, users will be able to identify services or software of interest, and store them for use later.
+This shopping basket metaphor extends to include services --- such as \gls{IDA} or batch compute facilities --- and workflows from the \pgls{OSSR} and other repositories: as they move through the system, users will be able to identify services or software of interest, and store them for use later.
 
 \subsubsection{Data Discovery and Staging}
 \label{sec:vision:capabilities:data}
@@ -170,7 +170,7 @@ For example, the way that data from the SKA will be analyzed is very different t
 It is therefore essential that \gls{ESAP} implement a flexible capability for interfacing with a variety of \gls{IDA} services.
 
 The architecture described in \cref{sec:vision:capabilities:ui}, together with the data orchestration system described in \cref{sec:vision:capabilities:orch}, are designed to make this possible.
-Specifically, \pgls{ESAP} provides an \glspl{API} through which \gls{IDA} systems can access the “shopping basket”, both to retrieve data items and to provide (appropriately authenticated) updates from the \gls{IDA} system as the user saves their analysis.
+Specifically, \pgls{ESAP} provides \glspl{API} through which \gls{IDA} systems can access the “shopping basket”, both to retrieve data items and to provide (appropriately authenticated) updates from the \gls{IDA} system as the user saves their analysis.
 The expectation is that the \gls{IDA} system will write substantial data products (such as output images) to bulk storage (such as the \gls{DIOS} data lake), and return references to them to \pgls{ESAP} for further analysis, but this can be adapted for specific project requirements.
 
 \subsubsection{Batch Data Processing}

contents/3-delivered.tex

@@ -34,7 +34,7 @@ The API Gateway is written in Python, using Django\footnote{\url{https://www.dja
 The API Gateway provides a rich, plugin-based system for adding new service integrations to \gls{ESAP}.
 It also provides an asynchronous job control system, shown in \cref{fig:esap:async}, which is used to manage long-running tasks like some queries (\cref{sec:delivered:data}) and batch processing jobs (\cref{sec:delivered:batch}).
 
-In principle, it would be possible for alternative or specialist user interfaces to communicate with the API Gateway using the same interface; as of now, however, the authors are aware of no other \pgls{ESAP} interfaces.
+In principle, it would be possible for alternative or specialist user interfaces to communicate with the API Gateway using the same interface; as of now, however, the authors are not aware of any other \pgls{ESAP} interfaces.
 
 \begin{figure}
 \centering

contents/8-conclusions.tex

@@ -12,4 +12,4 @@ However, it also presents an opportunity to go further: the \gls{ESAP} system pr
 Therefore, in \cref{sec:future} we described potential approaches to future work, both in terms of the organization of the project and the technical challenges which could be addressed.
 
 The conclusion of the \gls{ESCAPE} project marks the release of the first stable version of \gls{ESAP}, which may be accessed as described in \cref{sec:access}.
-However, we are optimistic that the system will continue to grown and evolve into the future, and we look forward to future funding opportunities which might support that evolution.
+However, we are optimistic that the system will continue to grow and evolve into the future, and we look forward to future funding opportunities which might support that process.

main.tex

@@ -2,6 +2,11 @@
 \usepackage{csquotes}
 \usepackage{subcaption}
 
+\Crefformat{section}{\S#2#1#3}
+\Crefrangeformat{section}{\S\S#3#1#4--#5#2#6}
+\Crefmultiformat{section}{\S\S#2#1#3}{ \&~#2#1#3}{, #2#1#3}{ \&~#2#1#3}
+\Crefrangemultiformat{section}{\S\S#3#1#4--#5#2#6}{ \&~#3#1#4--#5#2#6}{, #3#1#4--#5#2#6}{ \&~#3#1#4--#5#2#6}
+
 \input{meta}
 \input{changes}
 
@@ -9,7 +14,7 @@
 \setDocTitle{Final Assessment of the Performance of the Science Platform Prototype}
 \setWorkPackage{WP5, ESFRI Science Analysis Platform}
 \setLeadAuthor{John D. Swinbank (ASTRON)}
-\setOtherAuthors{Sara Bertocco (INAF), James Collinson (SKAO), Gareth Hughes (CTAO), Stelios Voutsinas (U.~Edinburgh)}
+\setOtherAuthors{Sara Bertocco (INAF), James Collinson (SKAO), Gareth Hughes (CTAO), Marjolein Verkouter (JIVE), Stelios Voutsinas (U.~Edinburgh)}
 \setDueDate{2022-11-30}
 \setDueMonth{M46}