Minor copyedits in appendices, e.g. parentheses

This commit makes some minor fixes following the hardwired non-numerical
solution to the cross-referencing issue between the main article and the
supplement, such as fixing "lineage like lineage" and missing closing
parentheses.

From Mohammad: while re-basing the commit over the 'master' branch, I also
added Boud'd name at the top of the copyright holders of the appendices.

2 files changed, 7 insertions, 5 deletions

diff --git a/tex/src/appendix-existing-solutions.tex b/tex/src/appendix-existing-solutions.tex
index aa6809f..09a8667 100644
--- a/tex/src/appendix-existing-solutions.tex
+++ b/tex/src/appendix-existing-solutions.tex
@@ -4,6 +4,7 @@
 %
 %% Copyright (C) 2020-2021 Mohammad Akhlaghi <mohammad@akhlaghi.org>
 %% Copyright (C) 2021 Raúl Infante-Sainz <infantesainz@gmail.com>
+%% Copyright (C) 2021 Boudewijn F. Roukema <boud@astro.uni.torun.pl>
 %
 %% This file is free software: you can redistribute it and/or modify it
 %% under the terms of the GNU General Public License as published by the
@@ -106,14 +107,14 @@ Apache Taverna\footnote{\inlinecode{\url{https://taverna.incubator.apache.org}}}
 A workflow is defined as a directed graph, where nodes are called ``processors''.
 Each Processor transforms a set of inputs into a set of outputs and they are defined in the Scufl language (an XML-based language, where each step is an atomic task).
 Other components of the workflow are ``Data links'' and ``Coordination constraints''.
-The main user interface is graphical, where users move processors in the given space and define links between their inputs and outputs (manually constructing a lineage like
+The main user interface is graphical, where users move processors in the given space and define links between their inputs and outputs (manually constructing a lineage, as in the
 \ifdefined\separatesupplement
 lineage figure of the main paper).
 \else
 Figure \ref{fig:datalineage}).
 \fi
 Taverna is only a workflow manager and is not integrated with a package manager, hence the versions of the used software can be different in different runs.
-\citeappendix{zhao12} have studied the problem of workflow decays in Taverna.
+Ref.\/~\citeappendix{zhao12} studied the problem of workflow decays in Taverna.
 
 
 
@@ -387,7 +388,7 @@ It just captures the environment, it does not store \emph{how} that environment
 The Research object\footnote{\inlinecode{\url{http://www.researchobject.org}}} is collection of meta-data ontologies, to describe aggregation of resources, or workflows, see \citeappendix{bechhofer13} and \citeappendix{belhajjame15}.
 It thus provides resources to link various workflow/analysis components (see Appendix \ref{appendix:existingtools}) into a final workflow.
 
-\citeappendix{bechhofer13} describes how a workflow in Apache Taverna (Appendix \ref{appendix:taverna}) can be translated into research objects.
+Ref.\/~\citeappendix{bechhofer13} describes how a workflow in Apache Taverna (Appendix \ref{appendix:taverna}) can be translated into research objects.
 The important thing is that the research object concept is not specific to any special workflow, it is just a metadata bundle/standard which is only as robust in reproducing the result as the running workflow.
 Therefore if implemented over a complete workflow like Maneage, it can be very useful in analysing/optimizing the workflow, finding common components between many Maneage'd workflows, or translating to other complete workflows.
 
diff --git a/tex/src/appendix-existing-tools.tex b/tex/src/appendix-existing-tools.tex
index 1d0b383..7efb7cb 100644
--- a/tex/src/appendix-existing-tools.tex
+++ b/tex/src/appendix-existing-tools.tex
@@ -5,6 +5,7 @@
 %
 %% Copyright (C) 2020-2021 Mohammad Akhlaghi <mohammad@akhlaghi.org>
 %% Copyright (C) 2021 Raúl Infante-Sainz <infantesainz@gmail.com>
+%% Copyright (C) 2021 Boudewijn F. Roukema <boud@astro.uni.torun.pl>
 %
 %% This file is free software: you can redistribute it and/or modify it
 %% under the terms of the GNU General Public License as published by the
@@ -306,8 +307,8 @@ Hence we will just review Git here, but the general concept of version control i
 
 \subsubsection{Git}
 With Git, changes in a project's contents are accurately identified by comparing them with their previous version in the archived Git repository.
-When the user decides the changes are significant compared to the archived state, they can be ``committed'' into the history/repository.
-The commit involves copying the changed files into the repository and calculating a 40 character checksum/hash that is calculated from the files, an accompanying ``message'' (a narrative description of the purpose/goals of the changes), and the previous commit (thus creating a ``chain'' of commits that are strongly connected to each other like
+When the user decides the changes are significant compared to the archived state, they can ``commit'' the changes into the history/repository.
+The commit involves copying the changed files into the repository and calculating a 40 character checksum/hash that is calculated from the files, an accompanying ``message'' (a narrative description of the purpose/goals of the changes), and the previous commit (thus creating a ``chain'' of commits that are strongly connected to each other, as in
 \ifdefined\separatesupplement
 the figure on Git in the main body of the paper).
 \else