BioSchemas / specifications

Issue tracker, technical wiki, and example markup
https://bioschemas.org
54 stars 52 forks source link

input/output new properties the same as object/result in CreateAction? #655

Open ljgarcia opened 1 year ago

ljgarcia commented 1 year ago

Original message by @ptsefton at https://github.com/BioSchemas/specifications/issues/653#issuecomment-1740468713

BTW, also as an outsider though the properties inputand output in particular ring alarm bells for me; these are semantically the same as or very close to, object and result on http://schema.org:CreateAction, as used here: https://www.researchobject.org/workflow-run-crate/profiles/process_run_crate. Not my project, but do you really need new terms?

ljgarcia commented 1 year ago

inputand output were proposed for the ComputationalWorkflow profile and later adopted as well by the ComptutationalTool profile. inputand output are of type FormalParameter so (my understanding) they are meant to represent an abstraction rather than an actual thing. Making a parallel to functions and function calls, FormalParameter is a parameter used when defining the workflow/tool, not an argument used when the workflow/tool is actually used. @nsjuty could you please follow up with ComputationalWorkflow group? You could also make the liaison with RO-Crates so we find out the way to go (hopefully a compatible way for both communities). Thanks.

albangaignard commented 1 year ago

@ptsefton, thanks for suggesting the reuse of object and result schema.org properties. Since these properties have for range Thing, I don't see anything againts refering to an instance of FormalParameter. So it would be ok for me to update the Bioschemas profiles with these schema.org properties.

The semantics would be a bit different since in Computational{Tool,Worflow} profiles, we focus on tool/workflows specifications and not their execution. My understanding of CreateAction is that it's more related to provenance metadata (what is actually done on a thing).

@stain, what is your opinion on the ComputationalWorkflow side ?

stain commented 2 months ago

On ComputationalWorkflow the reason we introduced a FormalParameter was because the input and are not the real thing/data, they are prototypes of that data. You could also consider a CreateAction that is in actionStatus http://schema.org/ PotentialActionStatus to be a prototype of the action -- in which case object is what the action would consume and result what it would produce. Now clearly result is there also a prototype (perhaps to a URL that does not work yet), but it's unclear if object is real or prototype.

The FormalParameter also gives space to provide a name/position to the parameter, although you could already do that using https://schema.org/Role (equivalent to roles in PROV-O).

Are you suggesting that in a ComputationalTool you talk about a potential execution, then you want to mix some real data inputs (e.g. --quiet) with prototypical inputs (some FASTQ sequence)?