Naming Conventions

[ZimmerA]

We should consider renaming the workflows folder. Right now, the workflows folder doesn't actually contain workflows but the different commandline tool wrappers while the actual workflows reside in the runs folder (see https://github.com/nfdi4plants/Hackathon_SampleRun for an example). In the context of CWL and Galaxy a workflow is a chain of tools that get executed one after another, while a commandline tool is just a wrapper for one tool/script/etc.

For this reason, I suggest renaming the workflows folder to something different, like computations or tools (other ideas are welcome)

[chgarth]

This had been given quite some thought before the specification. It is true that the term "workflow" is oversubscribed, meaning both "a sequence of computational steps" and the application of the former.

The "actual workflows" are conceptually independent of their input files and the results they reproduce. (This is true for CWL / Galaxy workflows in general). The ARC runs OTOH are instances of workflows. For the sake of convenience, they are also described using CWL, but they may name specific inputs etc. and are not expected to be reusable.

I don't think that tools, i.e. single-step workflows if you will, need a distinct place - as far as CWL is concerned, there is no distinction when including a tool vs. a workflow, and from what I gather, most workflows are not single tools. Compare e.g. the workflows on https://workflowhub.eu.

You are also correct in identifying that a strict separation between what goes in a run vs what is a workflow is not enforcable, but rather a matter of choice / philosophy. It should be ok – within an ARC – to have complex sequences of steps within a run's CWL description. Bundling / abstracting repeated steps in a workflow is often good practice due to benefits in terms of shareability and reusability, but not strictly needed for reproducibility.

PS other names previously considered for "runs": "computations" ;-), "pipelines", "results", ...

[ZimmerA]

I completely agree with everything you said, so I think there is a design problem in the example arc because, as it is right now, the workflows directory exclusively contains single step workflows (CommandLineTools) while the runs folder contains the actual workflow description (not just as an instance with inputs but the actual description of the workflow).

So from my understanding, it would be appropriate and compliant with the specification if we move all the tools inside the workflows directory into one parent directory, so the structure would look like workflows/proteomiqon/tool1/ workflows/proteomiqon/tool2/ etc. and inside workflows/proteomiqon we would have the workflow.cwl that would bundle all of them together to form the actual workflow.

A downside for this would be if 2 workflows need the same tool, we would either have duplicate tools in the workflow directories or weird pathing to other workflows.