diff options
| -rw-r--r-- | tex/src/appendix-existing-solutions.tex | 7 | ||||
| -rw-r--r-- | tex/src/appendix-existing-tools.tex | 5 |
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 |