The idea is that if i generate a cwl-abstract file now with this then, in the future, it could be updated(as in, generating a new version) when the full galaxy-cwl is working, which will produce executable cwl descriptions. So...look carefully what and how the executable cwl is being produced from galaxy in the galaxy-cwl project (see https://github.com/common-workflow-language/galaxy)
All steps in the CWL-abstract should have the same class ? something like Galaxy_step, how does this affects the evolution of the generated cwl-abstract to the real ones in the future? what is it actually being printed as class in the cwl-galaxy project?
The main thing that I should take into account to implement this is that all 3 ids (the one in the galaxy workflow file and the ones i set for cwl abstract in each case...from run or from static workflow), are the same in each step. -Take into account the different Galaxy workflow format versions AND the CWL versions: should I create different branches for the versions/combinations
Something similar to datatypes happens with tool/job information about the operation it is performing, ideally i would like to tag that using edam, but thats only available in a handful of galaxy tools, although it should be widely available if i look in bio.tools but there is no direct link between galaxy tools and bio.tools entries
The idea is that if i generate a cwl-abstract file now with this then, in the future, it could be updated(as in, generating a new version) when the full galaxy-cwl is working, which will produce executable cwl descriptions. So...look carefully what and how the executable cwl is being produced from galaxy in the galaxy-cwl project (see https://github.com/common-workflow-language/galaxy)
All steps in the CWL-abstract should have the same class ? something like Galaxy_step, how does this affects the evolution of the generated cwl-abstract to the real ones in the future? what is it actually being printed as class in the cwl-galaxy project?
The main thing that I should take into account to implement this is that all 3 ids (the one in the galaxy workflow file and the ones i set for cwl abstract in each case...from run or from static workflow), are the same in each step. -Take into account the different Galaxy workflow format versions AND the CWL versions: should I create different branches for the versions/combinations
Datatypes: when extracting input/output datatypes from Galaxy workflow steps, can I assume these datatypes exist in CWL? otherwise is there any way to convert them to CWL types? even if its not a 1-to-1 correlation. or what is the intersection between Galaxy datatypes and CWL types?. what about Galaxy tools that define specific types? CWL uses ontologies to define formats. The can be from IANA (https://www.iana.org/assignments/media-types/media-types.xhtml) or EDAM (https://www.ebi.ac.uk/ols/ontologies/edam/terms?iri=http%3A%2F%2Fedamontology.org%2Fformat_1915) See also https://www.commonwl.org/user_guide/16-file-formats/ For example, to indicate a bam file, it should be type: File label: Aligned sequences in BAM format format: edam:format_2572
Something similar to datatypes happens with tool/job information about the operation it is performing, ideally i would like to tag that using edam, but thats only available in a handful of galaxy tools, although it should be widely available if i look in bio.tools but there is no direct link between galaxy tools and bio.tools entries