Issues with ComputationalWorkflow properties

[ljgarcia]

@stain @CaroleGoble
Could you please look into the following issues with ComputationalWorkflow and FormalParameter profiles?

• FormalParameter
  • additionalType should not be used. That property was added to schema.org as a way to specify the rdf:type in either RDFa or microdata. It was used at the very beginning of Bioschemas and advised to be removed from all profiles later on.
• ComputationalWorkflow
  • Please add a Bioschemas description to creator, producer and publisher or examples so people understand the difference across them
  • keywords should have DefinedTerm as part of its range (it was added a while ago to schema.org)

[ljgarcia]

@nsjuty please move this forward, thanks

[stain]

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.