Open ljgarcia opened 1 year ago
@nsjuty please move this forward, thanks
Will try to add these, directly in https://github.com/BioSchemas/specifications/blob/master/ComputationalWorkflow/jsonld/ComputationalWorkflow_v1.1-DRAFT.json and https://github.com/BioSchemas/specifications/blob/master/FormalParameter/jsonld/FormalParameter_v1.1-DRAFT.json I assume?
The reason we deliberately used the weaker additionalType
and not @type
is that EDAM types like http://edamontology.org/data_2977 (Nucleic acid sequence) apply to instances (a FASTA file of sequences for instance), while the FormalParameter
is a placeholder for potential such files. It is referenced here more as a defined term than as a class that this object is an instance of. It was also seen as a way to tag such files on execution in provenance, which would then use @type
directly.
I don't think we can move this definition to @type
array as then it will get muddled up with the FormalParameter
type which would not apply to the output. The EDAM classes etc. are also not defined in schema.org nor Bioschemas. So I feel a separate property is needed, ideally one allowing a DefinedTerm
.
On the other hand we're using encodingFormat
directly even if to mean the syntactic format of the potential files. In this sense it is similar to using Action
both for potential and previous actions.
Perhaps the closest property beyond additionalType
would be genre but I feel it is a bit far.
If we make a new one perhaps hasParameterType
as it was called in myGrid ontology, but then that is pretty much the same as additionalType
.. So my preference would be to keep this but with a note on this usage.
@stain @CaroleGoble Could you please look into the following issues with ComputationalWorkflow and FormalParameter profiles?