search

fair-workflows / fairworkflows

A python library for constructing, modifying and publishing scientific workflows described using semantic technologies.
Apache License 2.0
12 stars 3 forks source link

Add semantic typing to is_fairworkflow decorator #161

Closed raar1 closed 3 years ago

raar1 commented 3 years ago

Similar to how this is done in PR #158 , allow the @is_fairworkflow decorator to take parameters to set input/output semantic types. Wait for #160 to be finished first.

svenvanderburg commented 3 years ago

I am thinking, 🤔 wouldn't the inputs (and semantic types) to a workflow always correspond to the inputs of the 'first' step. And vice versa for the outputs and the 'last' step? @raar1

Or do we still want to support different triples associated to inputs/outputs on the workflow level? (of course it would save work to not support it and just leave it as is)

raar1 commented 3 years ago

I am thinking, 🤔 wouldn't the inputs (and semantic types) to a workflow always correspond to the inputs of the 'first' step. And vice versa for the outputs and the 'last' step? @raar1

Or do we still want to support different triples associated to inputs/outputs on the workflow level? (of course it would save work to not support it and just leave it as is)

Well, in principle some of the inputs could be for steps other than step 1. For example it might be a string that indicates which ML model to use, and this wouldn't be used until, say, step 5. Or there could be two 'first' steps, both of which could run in parallel. So the inputs don't necessarily correspond to the first step as defined by the user. However, if it makes our code cleaner, we could always add our own 'First step' which is the 'Input' step, and returns the stuff used in subsequent steps. That might be quite a nice way to do it, reusing code that's already there. I think that would be a good idea.

svenvanderburg commented 3 years ago

We discussed it. Indeed it's a good point that the 'first' step does not necesarily correspond to the workflow-level inputs. But based on the steps alone we can define unbound inputs and unbound outputs which are inevitably also the workflow-level inputs and outputs. We don't expect that the user wants to control those wf-level inputs/outputs separately, and the information is already there in the steps RDF. So we close this issue for now.