Document challenges found using incremental FDOs in workflows #59
Labels
D8.4
Work associated with final deliverable - e.g. testing, sustainability, and documentation.
documentation
Improvements or additions to documentation
wontfix
This will not be worked on
Projects
Milestone
From #47 :
Another point for discussion: at the moment, every tool has openDS as input and code.py maps these to opends_properties. The drawback of this, is that every input variable needs to be munged into the openDS structure.
Take for example, GEORG: this has locality text string input. For this to be run as a standalone tool on a spreadsheet of data, the spreadsheet would need to contain (or be converted to) openDS objects.
Would it be better for tools to accept the inputs they actually require? Instead of each tool converting the openDS into the inputs, we would have instead an openDS mapper tool, which would take the openDS input, define the expected outputs which would be plucked from the openDS JSON, and then feed these into the subsequent tool.
So rather than openDS => tool we would have openDS => openDS mapper => tool.
Advantages: more in line with the way Galaxy is designed to be used. Also, there is a lot of code redundancy - each tool needs code.py to extract the openDS properties. Instead, there would be one tool that did this.
The text was updated successfully, but these errors were encountered: